gharris999 wrote: > Truthfully, I never did take ReallyPreventStandby's code to a "finished" > state. The toggle feature was supposed to be a execute:first == inhibit > sleep, execute:again == uninhibit. But I don't recall if I really > fleshed that feature out or not. I'd have to review the code and, > frankly, I don't even have a copy of ReallyPreventStandby currently > installed on any of my LMS boxes. > I have now had time to look at your ReallyPreventStandby plugin again Gordon. I am running it with caffeinate -i as the prevent idle command and pkill caffeinate as the allow caffeinate command with these set as "toggles". Contrary to what you remembered, the toggle setting means that the commands only need to be called once which is what we need in this case. It is when the toggle setting is not made that we end up with multiple invocations of caffeinate. I have only tested so far the case of preventing standby when any player is powered on - as set in the settings for the plugin.
(As an aside, I am using caffeinate as the current official command, not because I think the problems we have had are due to your own sleep inhibit command which also uses power assertions. If I was to get to production use with this I would copy the binary and invoke it under a different name.) Debugging the plugin and analyzing the code convinced me that in this case at least, the call of _killInhibitCmd() in the plugin's _hasResumed() is inappropriate, at least with these settings. It was having the effect of killing the caffeinate that had been started on resume - by a Touch sending its WOL to the server. I have now deleted that call and have found the operation to be much improved. However, occasionally the Mac Mini still goes back to sleep before the plugin has had a chance to make that call of caffeinate. If a Mountain Lion system is woken by an interactive user, say at the keyboard, it will stay awake until the idle timer expires - in my case 10 minutes. If it is woken by WOL it ignores the idle timer and goes back to sleep more or less straight away - unless the appropriate power management assertion is made in time. ReallyPreventStandby depends on polling the state of the system at 60 second intervals. If it has resumed, if players are busy, or if the server is scanning for import it calls the prevent standby command - in the case of my settings this is caffeinate -i. It seems that ML will sometimes be sent back to sleep before that call of caffeinate, in a separate process, has had time to set the assertion. The following comments are copied from my latest post at http://bugs.slimdevices.com/show_bug.cgi?id=8141 as I still believe that this as an issue for the LMS developers to consider. If you agree, please vote for the bug. My firm view is that the source of caffeinate I found, and other examples since, should only be used as an example of the code that needs to be used withing LMS itself. iTunes does this, as can be seen by running pmset -g when it is playing and not playing. Ideally we should avoid the need for polling and take the appropriate action whenever sleep needs to be prevented or can be allowed again. (There might need to be a grace period though before allowing it again as offered now by ReallyPreventStandby - especially if the Mac is allowed to sleep while players are left on.) If hooks could be provided for this within LMS, platform-specific code could then be called. (It might be that some third-party plugins or Apps may themselves need to invoke these - I am thinking of Triode's Spotify and BBC Player for example but again, if sleep was prevented as long as any SB was on this should not be necessary.) I am hoping that the code called via the hooks could be implemented in OSX via the PerlObjectiveC bridge. I will carry on looking at ReallyPreventStandby but I am now more or less convinced that in the case of Mountain Lion we will have to set the assertions and release them within LMS itself and not by invoking new processes to run other commands. ------------------------------------------------------------------------ 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 plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
