Music won't resume until I touch screen

[HiJack]

Originally Posted by Scott

we had a user write a simple test app on a system behaving like this, and it gave him the same behaviour, had to touch the screen for his simple app to receive the resume event. So, aside from the other things you said were working on resume, I was wondering more about centrafuse type applications such as Windows Media Player. So, if you have WMP playing music, CF not loaded, then do a standby/resume, does WMP resume playing the music when coming out of standby?

Scott do you think you can post the app so I can trouble shoot my system? I have done a restore and its working perfect, but a I am getting ready to slowly install all devices and do not want to accidently have the issue and just keep installing and loose track of what caused the problem.

[adrenaln]

Here is the test app in question, a couple of points though.

1: The app is provided as is, it has no exception handling and will crash if an error occurs.
2: Run resume.exe, a window will display with the current time updated every second. Hibernate your PC. Turn your PC back on, a message box will pop up once the resume event is received from windows.

PS: Also, just conforming that your windows is set up to use the welcome screen and that fast user switching is disabled. Make sure when you are testing that you have no mouse, KB etc connected, let us know what you find.

[Notre350z]

I've got the same problem.
I need to touch then screen (or centrafuse ?) to wakeup centrafuse.
(even worse, i need to press forward or backward after that to hear the music since play button does nothing but it's not the subject of this post)

I've got something interesting however:
if i hibernate when sygic drive is displayed as an embedded application in centrafuse, i can see that when the pc resume sygic recovers instantaneously (but centrafuse don't). So definitly applications not waiting for the resume event can recover without problem.

I'm using an external app which is able to start a command when the resume event is fired by windows and i can see that this app receives the event only after i touch the screen.

I'll try to find a way to see if centrafuse receives the resume event before i touch the screen or not.

Maybe a stupid question but is it really needed that centrafuse makes some actions (which ones?) on suspend and resume events ?

[adrenaln]

Originally Posted by BGH

Yeah this would be heaven sent. Any clues as to the solution?

Sorry man, cant give any clues to someone from the red camp.

Seriously though, the solution is in the form of a plugin. (Thanks David, Scott and team for an awesome (and well doco'd) SDK)

I am successfully detecting the computer's "resumption" however have ran into a couple of issues that I may need to chat to one of the flux guys about. I will spend some more time tomorrow to get my when around the issues.

Right now I'm off to bed, I've got a gutful of pi$$ from a good night out....

[Scott]

excellent work adrenaln, let me know if you need any help. also you can send me an email (scottpm@fluxmedia.net) and I can give you a direct line if we need to talk...

Thanks for the plug on the new SDK. Worked forever on those docs, nice to here they were noticed...

[Notre350z]

I've made my investigation in the msdn documentation and i'm pretty sure that the handler you're using is wating for the message
WM_POWERBROADCAST with reason PBT_APMRESUMESUSPEND

BUT PBT_APMRESUMESUSPEND is fired only when triggered by an input (mouse,key,etc)

MSDN -> WM_POWERBROADCAST Message (Windows)

Here are the messages that centrafuse receives when suspending:

WM_POWERBROADCAST dwPowerEvent:PBT_APMQUERYSUSPEND dwData:00000001
WM_POWERBROADCAST dwPowerEvent:PBT_APMSUSPEND dwData:00000000

When resuming, centrafuse first receives this message :

WM_POWERBROADCAST dwPowerEvent:PBT_APMRESUMEAUTOMATIC dwData:00000000

Centrafuse is still frozen...

Then, the following message is received by centrafuse when i move my mouse or press a key, and then centrafuse wakes up.

WM_POWERBROADCAST dwPowerEvent:PBT_APMRESUMESUSPEND dwData:00000000

I think you could just forget the PowerModeChangedEventHandler of .Net and just track the WIN32 messages above in your WinProc function.

I mean :
PBT_APMSUSPEND => suspend
PBT_APMRESUMEAUTOMATIC => resume
PBT_APMRESUMESUSPEND => forget

What do you think ?

[Scott]

excellent investigation. i think our users who have experienced this issue here have nailed down now that it's a .net problem. GREAT WORK EVERYONE!!!
Plugin not needed, now that we are almost sure that this is what it is, we definitely will give it a shot to use core windows messages to act on resume, instead of replying on the .NET powermodechangedevent....
Will try to have this in the next update, possibly the one after that though...

[HiJack]

OMG, yeaaaaaaaaaaaaaaaaaa way to go! The resume nightmare is soon coming to a end!!!!!!!!!

[Scott]

i've added the code for processing the raw windows messages, it will be in the next update.

But, it is a major change, because it could completely change where cf receives the event in relation to other apps (i.e. bluetooth), etc, etc,... It's working for me, but who knows...

So...
In the next update, after running CF for the first time, an xml value will be generated in [localappdata]/centrafuse/system/config.xml that looks like:

<USENEWSUSPENDRESUME>False</USENEWSUSPENDRESUME>

Exit CF, change the value to True so it looks like:

<USENEWSUSPENDRESUME>True</USENEWSUSPENDRESUME>

Run CF, now windows raw POWERBROADCAST messages will be processed for suspend/resume, instead of the .NET POWERMODECHANGED event...

So just to be clear, if you do not manually edit the config.xml and set that value to True, Centrafuse will process suspend/resume as it always has...

I hope this works!! Again, great job everyone, especially adrenaln and notre350z, you guys rock!!

[BGH]

Originally Posted by Scott

i've added the code for processing the raw windows messages, it will be in the next update.

But, it is a major change, because it could completely change where cf receives the event in relation to other apps (i.e. bluetooth), etc, etc,... It's working for me, but who knows...

So...
In the next update, after running CF for the first time, an xml value will be generated in [localappdata]/centrafuse/system/config.xml that looks like:

<USENEWSUSPENDRESUME>False</USENEWSUSPENDRESUME>

Exit CF, change the value to True so it looks like:

<USENEWSUSPENDRESUME>True</USENEWSUSPENDRESUME>

Run CF, now windows raw POWERBROADCAST messages will be processed for suspend/resume, instead of the .NET POWERMODECHANGED event...

So just to be clear, if you do not manually edit the config.xml and set that value to True, Centrafuse will process suspend/resume as it always has...

I hope this works!! Again, great job everyone, especially adrenaln and notre350z, you guys rock!!

Man this is fantastic news, this problem has really been getting on my nerves. Now the obvious question... when can we get our hands on this new version!?!?!?!