mherger wrote: > > The main problem I have found with WOL in ML is that OSX goes back to > > sleep after 30 sec unless some application sets a power assertion to > > prevent it. The attempts to use ReallyPreventStandby I proposed > earlier > > in this thread, and also the new version of PreventStandby in the > > current 7.8 nightlies, do not reliably get in fast enough to set the > > power assertion before that timeout. > > I've been thinking about this a little more. The problem I'm seeing here > > is that we're deliberately _ignoring_ the first activity event in LMS > after a resume, because a resume will _always_ trigger some activity, > whether a SB caused the resume or not. Now by the time _real_ activity > > happens, the OS has sent the computer back to sleep. We did introduce > this > way, as otherwise LMS would have kept the computer running even if it > wasn't being used. > > Now what I'd suggest to try next is this: we keep the system alive no > matter what. But if we were to discover a resume event, we wouldn't > leave > it running for our whole idle time, but only a minute or two. By then > LMS > would have seen some real activity to keep the system alive if needed. > > Otherwise we would no longer keep it awake for all our idle time, but > only > a few minutes. Makes sense? > > -- > > Michael
Thanks Michael but unfortunately no. Looks like you missed this from me when I posted my recent comments to http://bugs.slimdevices.com/show_bug.cgi?id=8141 ***** NB for both of these tests, I removed the code added by Michael to ignore player activity on system resume so as to improve the chances that pmset would be called in time. ***** The basic problem is with the polling approach - my logs showed that 60 sec polling was unreliable (not surprising for a 30 sec window given by powerd). More success with 30 sec polling (again no surprise perhaps). But 30 sec polling does not seem like a good idea. I ask again here, as I have asked you in private email, is it possible to identify places in the server code where we could call event-based prevent/allow sleep actions rather than allowing on polling? After all, the player wakes up the server for a reason - presumably that reason corresponds to events in the server code. On the server side, the events would be starting and finishing scanning. In response to players, starting and finishing streaming for example. With this approach, we really could take advantage of your suggestion of just keeping the system awake for a minute or two on resume. Perhaps this could just be initiated by the opening of a TCP connection from a player. You are the best judge of whether this is feasible, from your knowledge of the code, and from your knowledge of the situation with the future of LMS. ------------------------------------------------------------------------ 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
