nonnoroger wrote: > 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.The original rationale for the > 'grace period' after resume was to fix a specific problem with Windows XP. Many users (myself included) would see their systems go back into suspend 2 minutes after a WOL no mater what system power management settings they had configured. This problem was much discussed on forums at Microsoft and was difficult to debug because not every system exhibited this behavior. There was a small chorus of complains by windows SBS users that the stock PreventStandby plugin failed to prevent standby in this situation. So I added the 'grace period' as a work-around in the stock PreventStandby plugin and ReallyPreventStandby inherited that code.
Probably the proper thing to do is to test for the OS on resume and reset the counter to 0 only when the OS is windows. ------------------------------------------------------------------------ gharris999's Profile: http://forums.slimdevices.com/member.php?userid=115 View this thread: http://forums.slimdevices.com/showthread.php?t=95980 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
