09-y8 wallpaper problem

[Scroobius]

Hi Peter

Could this be the fastest support question to a new release. I was just posting to say that wallpaper does not work in 09-y7 when you posted 09-y8. Well I quickly loaded y8 to see if it resolved the problem. It does not!!!.

When running y8 in unattended the wallpaper does not load on the desktop.

Sounding lovely though on first try

All the best

P

[PeterSt]

To be honest ... something like this has been reported, but questions from me about it lead to, well, nothing. So, no opportunity to solve it.

Maybe this isn't an easy one though. So, if you (or anyone) can help to explain what it exactly is which won't allow to show the Wallpaper (maybe for the first track only) .. I'll be happy to solve it ! (and here it just works ... but you guessed that).

Thanks !
Peter

[Scroobius]

Hi Peter,

With y8 if I tick the "unattended" box and click "play" the xx player disappears as you would expect but the wallpaper does not appear on the desktop. With y4 the xx player disappeared and the wallpaper appeared on the desktop correctlly.

But there is something else I have just found out related to hotkeys. I have set up the hotkey many times in y4 and it always worked fine whether running in attended or unattended. With y8 hotkey works fine in "attended" mode. The environmental variable is correctly set and the message comes up correctly listing the y8 directory I am using. So in attended mode I can vary volume etc using keyboard keys - no problem.  But if I run xx in "unattended" mode the hotkey function does not work and on trying to use it I then get error messages stating "remote operation problem" (or similar) and xx stops working, I get loud white noise from the speakers and strangely the wallpaper then appears on the desktop. Very strange. These are problems I do not have with y4 - I used y4 again to check and it all worked fine.

Sorry to set you head scratching so late on a Sunday evening.

Let me know if there is anything else I can try - these are similar problems I was also experiencing with y7.

All the best

P

[PeterSt]

So, I guess these two must be related ...
White noise (which is different if I'm allowed to judge what you perceive) has disappeared here for a while, as AutoHotkey just works together with the Wallpaper. Which ... *of course* won't imply I don't believe you !!

What are your settings regarding this ? Prio's, Core Appointment Scheme, what you play (FLAC etc.), upsampling (type) ... Edit : Engine, Mode, Buffer setting ?
Start During Conversion ?
Copy to XX Drive ?

Thank you very much ... really appreciated. Sorry for all those questions.
Peter

[Scroobius]

Hi Peter,

All files are FLAC some 24/96 some 16/44 problems occur regardless of file type.  Attached are jpg's of settings BUT this happens regardless of settings. It happens whether I run engine #4 or engine #3.  For me 09-y8 works OK (including hotkey's) with engine#4 or engine#3 and regardless of settings provided it is in "attended" mode. Just to clarify the "white noise" the following sequence happens: -

1.  I press "play" in "unattended" xx player disappears but wallpaper does NOT appear
2.  player continues to play OK UNTIL I use any hotkey command at which something BAD happens as follows:
3.  the taskbar at the bottom of my screen won't come up from its auto hide position
4.  if I then open xx (I can still access it from a 3rd party menu I use but not from the task bar) and try to shut it down my pc appears to completely lock and presumably the USB disconnects because that is when I get the "white" noise or very loud buzzing noise.
5.  I then need to reboot to get anything working again.

Just a couple of things - when xx running in unattended and no wallpaper showing "changewp" is not running and system resources (for what its worth) show cpu usage 5 to 30% and memory 70%. Core duo processor.

I dont get any of these problems with 09-y4.

Hope that helps let me know if you need any more info.

All the best

P

[PeterSt]

Thanks for your extensive response !

Allright. What does happen when you also tick Running Time OSD and OSD Text ?


But now ...

3.  the taskbar at the bottom of my screen won't come up from its auto hide position

So, do you say this because you think I put it in auto hide mode (not so), or do you say this because YOU put it in auto hide mode ??
If *you* do this, it may be key to the problem ... (if the above mentioned OSD checkboxes not already help).

?
Peter

[Scroobius]

I ticked the Running Time OSD and OSD Text boxes. I then ran XX in unattended mode and after a delay of 30 secs the wallpaper was shown - the first time. The second time I did exactly the same the wallpaper came up after about a minute and then the computer crashed - Microsoft message came up stating that the computer would be shut down in 1 minute due to serious problem. It is currently going through startup repair sequence so it was a big crash. I did try AutoHotkey the first time the wallpaper came up and the little rotating circle came up in the middle of the screen that normally shows when xx has recognised the command but nothing happened the command was not executed.

The taskbar at bottom I always have in autohide and it works fine normally using 09y4 engine#3 its just that when problems occur it will not come up and then I know something serious has gone wrong.

Perhaps it is resource limitations causing the problems but why do I get these problems with enigne#3 running in 09y8 I could understand the low latency with engine#4 causing problems. Isn't engine#3 under 9y8 the same as 9y4 in resource requirement?

All the best
P

[PeterSt]

No, nothing changed to Engine#3. But, the showing of the Wallpaper did;
So, apparently ticking those OSD checkboxes is related; I must be able to do something with that.

Thanks !
Peter


PS: Notice that, as with the previous solved problem with not showing the Wallpaper at Attended, things went in a loop, eating your resources ... This may be similar.

[Scroobius]

I just noticed that there was a service mobsync.exe running that was hogging cpu (50% wow) I have disabled it (cannot imagine why I have not seen that before maybe it was not running when I have checked in the past.

Anyway I do not seem to have the crashing problems anymore but everything else is the same. Wallpaper only comes up if osd's are ticked and hotkey does not work.

all the best

P

[PeterSt]

Can you try the hotkey thing without the taskbar auto-hiding ?

[PeterSt]

Btw, I tested with autohiding, but I don't see the problem.

Wallpaper thing is solved. Will upload it later.

[Scroobius]

I tried it without taskbar autohiding but no change the problems persist

[PeterSt]

I really don't know what to think of this. Or what to ask.

Is it possible that you post a XX, X3 and X3PB log file right after this happened ? But I guess this will be difficult. But if you succeed, try to explain to me how your stopped the noise etc., so I can interpret the log files for it.

Thanks a lot.
Peter

[Scroobius]

Peter - what do you want me to replicate? I do not think the taskbar problem is directly relevant as it only signifies that something major has happened in the operating system because everything becomes locked including taskbar (i.e. I do not think taskbar is directly implicated). It is not really a problem now since I stopped mobsync.exe and now have more resources. But the other problems persist like AutoHotkey does not work - well it sort of does if wallpaper is loaded and I use a hotkey command to say increase volume one step (1.5db) nothing happens until I stop a track running via xx and then immediately the volume changes.
P

[PeterSt]

Paul, I too don't talk about the taskbar (auto-hiding) because it just isn't te cause. It's only inconvenient while the problem is there (I'm only letting you know I understand the problem (hopefully));

But what I want you to replicate is a tedious job, if not impossible. Ok, you could incur for the situation, and next imply a reboot and then grab the log files. But this is hardly I'd like to ask someone to do (or maybe I just did ).

Btw, can I take it that you tried this with the 0.9y-8ya version ?
Re: No Wallpaper at first track in 09y_7

If not, maybe that solves it, like for Johan it solved the Wallpaper problem which I really did not expect.

Kind of important : During further testing, untick "Show Mirror Back" in the CoverArt section; I have seen that certain combinations of "music folder registrations" (like Cue File + no Track Numbers or whatever) cause the working out of the track listing at the backcover run in a certain too long loop (think of 10 seconds) which together with the volume change may hold up the volume change and next internal buffers get mixed up. Do note though that this will not be your situation since you didn't get the Wallpaper to begin with, so it is just to be certain it is not this. When everything works (later, hopefully) you can switch it on again).

May it help you : if the volume change ends up in noise, indeed something will be holding it up. So, if possible you may examine TaskManager and the cpu graph to see what's happening. There *will* be a small peak always (right before you receive the noise), but after that things should turn back to normal. So, you might tell me what you see, and don't forget to mention the Appointment Scheme you used at that moment.
Btw, what surprises me, and what I only just saw, is that you are using Engine#3. I don't recall ever receiving any such noise from that one ...

One last thing : If you receive the message "something wrong with remote command" (similar) notice that there are two sorts of this message : one which ends with Playback must stop, and one which does not end with that, and only notifies you that the remote command couldn't be processed. Please indicate which of the two you receive, and (thus) how that message exactly is.
I am now starting to think you receive the first version of this (playback must stop), which just detects something went wrong, and you will be receiving a kind of static when all would continue, but which is prevented (uhm).

Sorry for the inconveniences ...
Peter

[Scroobius]

Where do I find the log files?

[PeterSt]

Tick the Log Activities at the bottom in the Settings Area;
After playing you will sets of (belonging) XX, X3 and X3PB log files in the TemporaryData sub folder under your current XX folder ...

Thanks !

[PeterSt]

No further news ?

[Scroobius]

Apologies for the delay but have been busy I will work on it later today and post the log files for you.

Thanks for your help

P

[Scroobius]

Hi Peter - I loaded 8a and wallpaper problem OK now except that when xx has finished playing all files in the playlist and xx interface appears back on the screen the wallpaper stays up - it used to unload I have to press "stop" to unload the wallpaper. The hotkey controls do not work in unattended but they DO work fine in attended. Log files are attached but the following is the sequence I followed:

1   open xx
2.  using keyboard hotkey controls I checked that the volume control moved up and down which they did fine
3.  I ran xx in attended mode and checked that hotkey control volume worked which it did with no problem
4.  I then ran xx in unattended mode and tried to vary the volume using hotkey controls there was no change to the volume but each time I pressed a command the little revolving circle in the middle of the screen showed that something was "trying" to happen
5.  music continued to play ok but "something wrong at remote control" message came up
6.  I opened xx and pressed "stop" whereupon the wallpaper disappeared and the music stopped (correctly !!)

Sometimes in step 6 when I stop xx there are more serious problems like the USB disconnects and there is "white" noise

Log files attached

All the best
P

[PeterSt]

It is *not* using Arc Prediction where it goes wrong ...

It just took me 40 minutes to proove that (so many combinations). And if you wouldn't have used a hires file (which you did before as well), I would still have been on the wrong track, while ... hires is totaly unrelated. Haha.

Something to do ...

Thanks a lot for your time Paul.
Peter

[PeterSt]

This is solved in 0.9y-8c (upcoming).

A small disclaimer : I can't 100% proove "this" caused your noise, but for anything else but Arc Prediction (or DAC Needs = 24 bits / implied 16 bits !) an old method was used for the Volume Change, causing loads of overhead, that most probably causing the internal stream to (sort of) stall.

Again, thanks for your time.
Peter

[Scroobius]

I have loaded 8c and the wallpaper problem is solved but the Hotkeys still do not work in unattended mode - they do work in attended.

If I use Hotkeys in unattended it still causes problems like USB output stopping white noise etc.

Regards

Paul

[PeterSt]

I was afraid of that Paul.

Please try to help me. Try to find something that works (internal mobo soundcard ?), and from there on try to make clear to me what's actually happening. I know you should be using DAC Needs = 24 bits, but I tried that too (and sure needed to change to code for it, so I was a *little* hopeful).

I just can't think of anything further myself. What I do think do, is that it actually should be an easy thing ON YOUR SIDE. Yes. Let me give one example to get the idea :

The eally only thing we should be talking about is the digital volume, right ? (but if not, tell me, it drastically changes things). Now, whether you use that in Attended or Unattended mode, really doesn't make a difference. Not anymore, not since 0.9y-8c. So, whether you press Alt-U during Attended or during Unattended, can't matter. BUT : With Unattended you may have the Wallpaper showing, and with Attended you may not. And so you see, there *is* a difference, and it is you who can notice such a thing.

Please tell me SOMETHING ...
Peter

[Scroobius]

So my challenge is ....... I am going to have to work on this one. Anyway just for starters I did try using the mobo sound card Realtek and no difference the Hotkey still does not work in unattended. So I will now have to get my thinking hat on ...............

[PeterSt]

I don't understand ... Maybe you "molested" the xx.ahk file ? you know, the commands for Unattended are different from the Attended ones ...
Also important : You seem to be the only one ! (but if not, please (others) report !!).

If there's anything you want me to do or test, let me know Paul. I hope that we will laugh over this afterwards ...
Peter


PS: But to be sure, maybe get the xx.ahk from the latest 0.9y-8.

[Scroobius]

Now its getting crazy! I had made some changes to the ahk file and so decided to start again a completely new install of 8c and hotkeys again from scratch. I have reinstalled 09-y8 and updated to 8c but not installed hotkeys yet. But now I have problems I cannot get xx running. Before I go any further I notice that xx is picking up its old settings - I would like to start completely from scratch how do I do that how can I stop xx picking up its old settings - and is there anything else I need to completely remove everything.

[PeterSt]

How to delete a misbehaving ConfigFile.

Just throw out everything under Phasure ...
That should do it. There isn't anything anywhere else.

[Scroobius]

Thanks - well something did get screwed up in the config file and now after a complete scratch install XX is working fine again at 8c. So then I reinstalled Hotkeys and ................ the same problem they work in attended but not in unattended. If I try to use them in unattended I still get "problem at remote control" error message.

I am running out of ideas - the only thing I can think to try is to go back 09-y4 and see if Hotkeys works in unattended which it always used to. I made a complete new install of Hotkeys deleting everything before reinstalling.

 

[Scroobius]

Well I reloaded 09-y4 and Hotkeys and they work fine in both attended and unattended.

So I went back to 09-y8c and Hotkeys are still a problem in unattended. BUT I had only been using volume controls altU and altD I tried altE altP and altS and they appear to work OK. So it does appear to be only the volume controls that do not work in unattended in 8c (for me anyway) - that has to be very strange!!!

P

[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 ...

[Scroobius]

OK done that and there is no difference still the same problem.

If I am running in unattended and I call up the xxhighend GUI with altx I can then change volume using hotkeys.

P

[PeterSt]

Grrr ...

Ok, now I want to know whether - and how much those commands are being processed by XXHighEnd ...

Be sure to have a TemporaryData folder under your current XX folder (it isn't created automatically in this version per a bug).
Set the Loggin On.

Start Playback as always (Unattended), and use Alt-U one time.
Wait one minute or so.

Don't touch anything further, but get the XX and X3 log files (X3PB is not necessary), and post them.
Notice that in order to do this conveniently you should have an Explorer instance running, so you can grab the files.

After you caught the files, you can stop playback.
If you want of course.

Sorry AGAIN for the troubles ...
Peter

[Scroobius]

here they are

[PeterSt]

Thanks Paul.

If you look in the second XX file, you see an access violation to a path\file.

If you can find the file, you don't have the rights to change attributes of it. Somehow.
If you can't find the file, you have no rights to create files in that folder. But I can't imagine that ...

There's the actual impossible option that you can't find the file because it is hidden, but then I don't know what went wrong. So all 'n all it should be about "no change attributes rights". Well, maybe you heard of that ...




ANYWAY, this is the cause !

[Scroobius]

interesting and I cannot see anything immediately wrong but I will have a look at it and let you know how i get on
Thanks
Paul