nonnoroger wrote: > 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. > 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.
After the fix to ReallyPreventStandby I have let my system sleep after the grace period set in the plugin settings (I have it at three minutes), woken it again from a Touch and started playing a total of 10 times now. Out of 10 I found it did not honour the grace period once (going back to sleep as soon as I turned off the touch). So far it has not gone back to sleep while playing - although it did this once before my last post. So my fix to ReallyPreventStandby has very much improved things. Is anyone else prepared to try the fix and give us your experience? ------------------------------------------------------------------------ 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
