09-y8 wallpaper problem

[PeterSt]

that has to be very strange!!!

You can say that again. I'm stumped.

If I try to use them in unattended I still get "problem at remote control" error message.

Is this right after a FIRST (e.g.) Alt-u attempt ?
Notice that if a first won't work, a next will give this message after a few seconds. I think it is important to know the correct answer to this.

Is this also with Engine#3 ? (sorry if I asked the question already).
And now the Wallpaper works ... is it also thee case when you shut off all the Wallpaper checkboxes and OSD stuff ?

Really, the only thing I can think of is that your PC doesn't get around to process the command, so it should be a matter of finding out why. Unattended is only different to this respect because of Wallpaper/OSD stuff, though depending on your settings. So shutting it all off should make Attended and Unattened equal ...

[Scroobius]

OK answers are:

the "problem at remote control" message comes up only after 2nd or more attempts at AltU or D
yes this problem happens with engine#3 and #4 no difference

If in xx I turn off wallpaper and run in unattended mode (so xx user interface disappears and nothing comes up on the desktop) I still get the same problem the altu and d functions do not work and I get error message after 2 or more attempts. By the way I sometimes do get problems with altE & altS commands but not all the time. altu & d are always a problem.

But the next thing is interesting. I always run with the windows taskbar at the bottom of the screen in Autohide. This means that with xx running in unattended and wallpaper showing I can move the pointer to the bottom of the screen the taskbar comes up so that I can still access the computer. Now if I run xx in unattended the wallpaper comes up and obviously altu and altd will not work. BUT if I move the pointer down the taskbar comes up revealing icons I have placed on the taskbar among which is the xx icon. I click the xx icon which then brings the xx user interface back up (over the top of the wallpaper) so with xx still playing music, the wallpaper showing and the xx user interface back up I can then use altu and altd to change the volume. BUT sometimes I press altu and the vertical bar at the left side turns green stays green and nothing happens. So perhaps the same problem but less often but note that that happens sometimes in attended anyway.

My laptop seems to have enough resource available as far as I can tell.

All the best

[PeterSt]

Sorry for not answering sooner, but I guess I need time to get new ideas.

About the taskbar and bringing up XX and change the volume : Since the latest version this is just possible, so it is not a strange thing.
NOTE : The fact that the bar stays green doesn't tell much because that always was a kind of flakey. However, the volume should change (best seen by the Wallpaper volume setting). If that doesn't happen, it could indicate the same problem (but why not always ? beats me).
Notice though that again since the last version (which would be 0.9y-8c !) the green bar hardly shows, if at all. It is reset faster than the volume changes (which always has been the case afaik), but the volume changes much faster now.

I think the clue must be somewhere around Engine#3. I mean, this one never interfeared with the sound before (meaning : it gets distorted from a volume change), and nothing has changed to it. Notice : Engine#4 is quite another matter, because inherently it indeed can get distorted because of a, say, out of sync (this too though, never happens with me anymore). So, I guess all tests regarding this should be with Engine#3, to exclude the potential possibility of Engine#4 doing it for other reasons.

Allright. I don't think you ever said that Engine#3 created "noise" after Alt-U/D and I assume it just doesn't. So, I also assume that in that case the command just doesn't come through, but since this is detected you will be receiving the "problem at" message.
Now, it still *must* be so the command doesn't get processed because of some lack of resources, but before I didn't think about this just can be the disk. For instance, when you would be able to spin down your disk after, say, a few seconds, while in the mean time it takes 15 seconds to spin it up (which goes automatically when needed), you will be having this exact problem. It is a long shot, but maybe that can happen (spin down too fast).

In either case, maybe you can orient yourself towards this somehow. Ultimately you can try to install XX on one of the data disks (assuming you have them), and see whether things change. If you already have installed XX on a data disk, do it the other way around, and install it on the OS disk (the latter is the sure advice anyway !).
So, all 'n all think "disk" for a while, and maybe it brings something new.

Lastly I wanted to ask you whether you can please again post the XX, X3 and X3PB log files from a trial. The point is, before 0.9y-8c things really worked wrongly in some circumstances, which your before log files actually shows. So, now things are allright (as far as I am concerned at the moment) I'd really like to see them again.

Thanks again for your time Paul.
Peter

[Scroobius]

answers to your points

volume mostly changes immediately & green bar hardly shows but sometimes green bar does stay green & when it does the volume does not change.

all tests now I will do with engine#3 but as far as I can tell the problems have been the same with enignes #3 & #4.

I have now moved 8c to c:\ drive before it was on data disk. After everything set up with 8c on the c:\ drive the same problem happens. In unattended the altd and altu commands do not work and I get "problem at" message after a couple of attempts. Having tried altd or u and nothing happens I then can use alts or alte to stop or pause the player and those commands work OK. If I use alte for example and then bring up the xx user interface then the volume correctly shows at the new requested level ie if I had pressed altu once then the volume would have moved up 1.5db which seems to happen immediately after pressing alte.

As mentioned before I always set the task bar to "autohide" so that I can get to controls in unattended and when running in unattended it is grey background I guess because dwm.exe is stopped - fine no problems. But when running in unattended & I press altu or d I then cannot get the task bar to come up and sometimes worse I then get white noise (but I have not yet had this with engine#3 on c: disk) but I seem to remember it has happened in the past and I will keep checking and will let you know if it does happen with engine#3.

attached are log files I cannot get all on this post so will make another post with the others

All the best

P

[Scroobius]

more log files attached

[Scroobius]

and last log file

[PeterSt]

Again, thank you for all that work Paul.

Somehow the crux must be in your auto-hiding of the Taskbar. I may have asked you before to undo that and try ?
But maybe you make a combination which is "not allowed" ... (at this moment I must look at the log files again, but alas) ... I can imagine that you do NOT shut off the services, but use the Alt-u etc. in the mean time. If that is so, I wonder whether everything will ever be capable of things with those services still running.

So, just an idea, and maybe you just shut off the services already. But if not ... I like to bet that is it ...

?

(going to look at the log files now)


PS: And try it without the auto-hiding of the taskbar !

[PeterSt]

Hmm ... The log files don't even tell me whether you shut down the Services. Do you ?

[Scroobius]

"stop service" option is selected so yes

[PeterSt]

Maybe I found something;

I, say, formalized some things, implying that routines are being called during the startup of XXHighEnd - which always should have been called, but apparently (!) didn't because of twirks in the whole initialization which is a kind of vague because of so many things happening and triggering eachother. This is also related to things formally (mind this word again) being right or wrong, and when wrong it is a bit of a wild guess what will happen. Now :

The things being formally more correct now, I suddenly had the problem myself, and after a few hours of searching I found the problem. This is about an explicit stop of playback, if only the routine concerned is called during the initialization. If not (which happens in your version), nothing is the matter (by accident). Notice that I could not proove that 0.9y-4 was doing this allright or not, because in that situation the routine just could be called or not, and it didn't matter.

It only needs the explanation why in your case that routine is called (if so at all), and not with me or others. The only thing I can think of which can be different is that I'm using dot-net 3.5, while you easily can be using 3.0 and *that* is causing the problem. So, 3.5 would be wrong (at not calling routines while it should) and 3.0 could do that correctly - while in the mean time that routine was wrong because of my fault.

If the next version (0.9z) solves it for you, indeed this was it.
We'll keep in touch about this,
Peter

[Scroobius]

mmmmm interesting anyway I have dot.net 3.5 sp1 and I look forward to z

all the best

P

[Scroobius]

Hi Peter,

Well 09zb is up and running and I will report on sound quality when I have spent a few days with it.

But hotkeys problem remains - like the previous 09y hotkeys do not work in unattended mode (they do in attended). If I press alt U I get the spinning disc showing that a routine is attempting to run but the volume does not change. And I can wait as long as I like the volume does not change but if I then press alt X (while a track is playing) then just as the XX player interface comes up on the screen the volume changes.

All the best
Paul

[PeterSt]

Paul - Suppose right before playback you bring up TaskManager. You you start playback - Unattended. Does XXHighEnd actually disappear from the running processes ? (so look at the processes, not the applications).

Assumed it does (so that is right), you can set both priorities to Nothing, reboot and try it again (the TaskManager thing is not needed anymore).
If you already tried that before, let me know, but in either case let me know the result.

And wasn't it so that earlier on you told me that sometimes it works ? If that is (still) the case, you really should play with the Priorities and Appointment Schemes to find out which combination works best. Notice that it should work always, but if your laptop is stressed to begin with (dedicates all to keep the music playing) it isn't going to work. But first let's see whether you can bring some improvement; if we know what helps, I can try to improve on *that* again.

Regards,
Peter

[Scroobius]

Hi Peter - yes xxhighend does correctly disappear from the list of running processes in unattended.

Not sure I understand "set both priorities" to Nothing. If I left click on xxhighend process in "Taskmanager" I can set it to "Low" but it always returns to "Normal". I assume engine3(4) has to be realtime.

Also it does seem now (and recently with 9y) that every time I try to use hotkeys alt U & D in unattended it does not work. But it nearly always works in attended although it does occassionally get stuck (with green bar showing).

I would not say that my laptop is unduly stressed now. It used to be and that was the main reason I used unattended because xx did not work consistently in attended (tracks did not change properly engine3(4) stopped frequently etc. ). But then I spent many evenings killing lots of microsoft stuff running in the background that was not needed (and there was lots).

Now it works fine in unattended and the fan is less used!! Teskmanager shows CPU at 6-8% and physical memory < 60% with xx running attended I know that is not the whole story but I think that xx runs fairly OK now.

All the best
Paul

[PeterSt]

Not sure I understand "set both priorities" to Nothing.

I am sorry, and I could expect you to be confused with that TaskManager screen ... So .. No, I meant the PlayerPrio and ThreadPrio in the Settings Area of XX.

Ultimately you could try to set the PlayerPrio even higher than the ThreadPrio ...