- September 15, 2006
- 424
- 14
- 65
- Home Country
-
United Kingdom
- Thread starter
- #11
Hi Guys,
Right I think I'm beginning to understand what is going on! According to the following:
http://msdn2.microsoft.com/en-us/library/aa373235.aspx
If a system is suspended and then woken up using a timer (rather than by a user), then it will re-suspend automatically after 2 minutes unless it is "busy". This seems to match exactly what I'm seeing. For an EPG grab the system wakes up and starts the grab but after two minutes it gets suspended, if the grab has completed, if not hard luck! For recordings what seems to happen is that if the recording starts within two minutes then the recording is made ok, but then two minutes after the recording stops the system gets suspended. If it takes more than two minutes for the recording to start after the wakeup then the system suspends and the recording is missed.
Basically to stop the automatic suspend then the application has to call SetThreadExecutionState to indicate what it is doing. MP does this as it wakes up to turn on the screen (if the option to turn on the screen is set), it also does this as part of the wakeup sequence (take a look at PowerManager.cs). But in both cases it only indicates that it is busy for a very short time, after which it indicates that it is no longer using the screen or the system by making another call to SetThreadExecutionState.
I'm not 100% sure what the correct fix for this is. It looks like the original code in PowerManager.cs was setup to handle this case by expecting that the call to OnPowerUp would not return until the system had finished doing whatever it had woken up to do. However in the present code this simply calls the OnWakeupTimer function in PowerScheduler.cs which just writes a log entry and returns.
Perhaps now that PowerScheduler calls its OnTimer function every 30s or so while the system is running under its control maybe it should make a call to SetThreadExecutionState(ES_SYSTEM_REQUIRED) (note no ES_CONTINUOUS) to indicate that the system cpu is still required and to prevent the system from suspending. Perhaps the correct place to call this would be whenever SetTimer is called since in this case clearly PowerScheduler is expecting that the system will continue to run until the timer goes off.
What do you think? Are there any situations when the PowerScheduler system is not running its timer but the system is still active? Is there a better way to do this? One downside of the above is that doing this may prevent a system activated suspend from taking place (but not one that was triggered by the user). Do people use both the system suspend and PowerScheduler to suspend their system at the same time?
I think I may give this change a try in my private build. I'll report back how it goes!
Hope the above make sense....
Andy
Right I think I'm beginning to understand what is going on! According to the following:
http://msdn2.microsoft.com/en-us/library/aa373235.aspx
If a system is suspended and then woken up using a timer (rather than by a user), then it will re-suspend automatically after 2 minutes unless it is "busy". This seems to match exactly what I'm seeing. For an EPG grab the system wakes up and starts the grab but after two minutes it gets suspended, if the grab has completed, if not hard luck! For recordings what seems to happen is that if the recording starts within two minutes then the recording is made ok, but then two minutes after the recording stops the system gets suspended. If it takes more than two minutes for the recording to start after the wakeup then the system suspends and the recording is missed.
Basically to stop the automatic suspend then the application has to call SetThreadExecutionState to indicate what it is doing. MP does this as it wakes up to turn on the screen (if the option to turn on the screen is set), it also does this as part of the wakeup sequence (take a look at PowerManager.cs). But in both cases it only indicates that it is busy for a very short time, after which it indicates that it is no longer using the screen or the system by making another call to SetThreadExecutionState.
I'm not 100% sure what the correct fix for this is. It looks like the original code in PowerManager.cs was setup to handle this case by expecting that the call to OnPowerUp would not return until the system had finished doing whatever it had woken up to do. However in the present code this simply calls the OnWakeupTimer function in PowerScheduler.cs which just writes a log entry and returns.
Perhaps now that PowerScheduler calls its OnTimer function every 30s or so while the system is running under its control maybe it should make a call to SetThreadExecutionState(ES_SYSTEM_REQUIRED) (note no ES_CONTINUOUS) to indicate that the system cpu is still required and to prevent the system from suspending. Perhaps the correct place to call this would be whenever SetTimer is called since in this case clearly PowerScheduler is expecting that the system will continue to run until the timer goes off.
What do you think? Are there any situations when the PowerScheduler system is not running its timer but the system is still active? Is there a better way to do this? One downside of the above is that doing this may prevent a system activated suspend from taking place (but not one that was triggered by the user). Do people use both the system suspend and PowerScheduler to suspend their system at the same time?
I think I may give this change a try in my private build. I'll report back how it goes!
Hope the above make sense....
Andy
