- September 15, 2006
- 424
- 14
- 65
- Home Country
-
United Kingdom
- Thread starter
- #21
Hi Bavarian,
I've not had chance to test the latest svn for long yet but looking at the code change I think there may be a problem. The PowerManager.ForbidHibernation call is designed to be called as a pair with PowerManager.AllowHibernation and it has a counter in it such that if it is called more than once it will not call the SetThreadExecutionState a subsequent time (unless the AllowHibernation call has been made a matching number of times). So calling it multiple times from OnTimer may cause problems.
It seems to me there are a couple of possible solutions. If you think you can track all of the ways in which the system can resume and enter suspend then you could call ForbidHibernation (when the system starts and wakes up) and AllowHibernation (at exit and when it suspends) at each point, however you would have to ensure that they always matched, not sure if this is possible. Alternately you could create a new method in PowerManager like:
static public void SystemBusy()
{
// Let the system know we are busy and so not to hibernate
SetThreadExecutionState(ExecutionState.SystemRequired);
}
Which basically says that the system is in use (note that it does not use the Continuous flag as it is expected to be called reasonably frequently, and doing it this way should not interfere with other calls to SetThreadExecutionState) . The above would then be called from OnTimer.
Do you know if anything else uses the functions in PowerManager? I couldn't find any other references. If there are none then maybe it would make sense to remove the Allow/Forbid code and simply rely on the above, to indicate the busy state of the system.
Just a thought
Andy
I've not had chance to test the latest svn for long yet but looking at the code change I think there may be a problem. The PowerManager.ForbidHibernation call is designed to be called as a pair with PowerManager.AllowHibernation and it has a counter in it such that if it is called more than once it will not call the SetThreadExecutionState a subsequent time (unless the AllowHibernation call has been made a matching number of times). So calling it multiple times from OnTimer may cause problems.
It seems to me there are a couple of possible solutions. If you think you can track all of the ways in which the system can resume and enter suspend then you could call ForbidHibernation (when the system starts and wakes up) and AllowHibernation (at exit and when it suspends) at each point, however you would have to ensure that they always matched, not sure if this is possible. Alternately you could create a new method in PowerManager like:
static public void SystemBusy()
{
// Let the system know we are busy and so not to hibernate
SetThreadExecutionState(ExecutionState.SystemRequired);
}
Which basically says that the system is in use (note that it does not use the Continuous flag as it is expected to be called reasonably frequently, and doing it this way should not interfere with other calls to SetThreadExecutionState) . The above would then be called from OnTimer.
Do you know if anything else uses the functions in PowerManager? I couldn't find any other references. If there are none then maybe it would make sense to remove the Allow/Forbid code and simply rely on the above, to indicate the busy state of the system.
Just a thought
Andy
for waiting for me. I have been testing this todat withvarious different setting and can confirm that I can have now schedule recordings as expected and the PC is not returning to Suspend too early.