I have been looking at (part of) the history of ReallyPreventStandby at
http://bugs.slimdevices.com/show_bug.cgi?id=8520 and have a couple of
questions (for Gordon and anyone else following who might remember the
issues).
Gordon, you said then:
The version I came up with makes PreventStandby work a little harder.
When the timer code gets executed, it checks for the following states:
Players playing, players updating (firmware updates) the scanner running
*and it detects if the system has recently resumed from standby or
hibernation*. If any of these conditions are met, the timer code zeros
a countup variable that otherwise gets incremented every minute. (Stars
mine.)
Which I can see from the code it still does:
if ( _hasResumed($currenttime) || _playersBusy() ||
Slim::Music::Import->stillScanning() ) {
$g{nHasBeenIdle} = 0;
(My change so far has been to remove the side-effect of calling
_hasResumed which was to enable sleep.)
I understand the reasons why it makes sense to have a grace period after
a SB has been turned on for the user to select what he or she wants to
play.
But the problem is with the current logic that we are imposing this
grace period on every wake of the system (OSX and Mountain Lion in
particular is my immediate concern). hat is not of much issue if the
grace period is less than the idle timeout and the machine has been
woken by an interactive user at the keyboard. But if it is a WOL from
some other device than a SB we should not be imposing the LMS grace
period.
I noticed this by looking at the ReallyPreventStandbylogs while my
system was being woken up by a WOL probe from an AppleTV.
I will have a go at fixing the logic tomorrow.
------------------------------------------------------------------------
nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=95980
_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/plugins
