OSX Mountain Lion sleep issues

[danco]

But the bug report I am asking people to vote for goes back years.

Yes, but the problem occurred because some machines (not all, I think) simply did not behave the way Apple stated that sleep worked. That is, they would sleep even when there was hard drive activity, although Apple specifically stated that hard drive activity prevented sleep.

It would have been a nice feature if Logitech/SlimDevices had worked round this, but it was hardly a bug .

I am not sure if you mean it is an issue for Apple to sort out or an Apple-specific issue for Logitech. My view is that Apple at last have it right. I think it is great that my Mac Mini will at last go to sleep reliably after the time I have set in preferences. It is each App that knows best whether it needs to override these defaults. With the power assertions they have at last given the tools that allow App developers to implement this.

I agree with you. Power assertions seems a good way to go. I wonder if Apple just decided that hard drive activity simply did not prevent sleep reliably enough, and decided to provide power assertions.

Sorry but this is the wrong way round. We should not need Caffeine anymore if developers cotton on and adapt their programs for ML. I would worry that providing such a menu bar facility would give developers a get-out from doing so. Using caffeinate directly from the command line gives us all we really *need* in the mean time - apart from convenience.

We should not need third party sleep timers or third party keep-awake timer kludges.

Logitech, along with other developers need to be pushed to take advantage of power assertions under ML.

I partly agree. Certainly developers need to take advantage of power assertions. I am not sure that it is a matter of "pushing", as developers do need time to respond to the changes in ML.

caffeinate from the command-line is, as you say, all we *need*, but a double-clickable file (even if not a menu bar item) is *much* more convenient. I have several programs that are still useful but are no longer being developed, so caffeinate (via command-line or shell script) is needed. And others where from time to time I want my computer and display awake, so that I can see what is going on with them.

[nonnoroger]

Turns out that kIOPMAssertionTypePreventSystemSleep has been available since OS X 10.7 (Lion).
See http://developer.apple.com/library/m...reference.html

Power Assertions in general have been with us since 10.6.

The pmset -g command is a good way to see how Apps are using these facilities - for exampe try playing something in iTunes and run pmset -g.
EyeTV is an example of a third party App that does the same.

[jdwek]

I am surprised you say the bug has been around for years. When I had Lion 10.7 my media server played fine. From my understanding ML took the sleep issue to an extreme and now LMS does not prevent sleep. I wonder if the problem is related to the lack of a PowerNap firmware addition that allows continued had disk function while sleeping on Laptops. Powernap is not available as yet on desktops.

[danco]

As I understand it, under ML hard drive activity does not prevent sleep.

Previously, it was *supposed* to prevent sleep, but this worked for some people and not for others.

[nonnoroger]

I am surprised you say the bug has been around for years. When I had Lion 10.7 my media server played fine. From my understanding ML took the sleep issue to an extreme and now LMS does not prevent sleep. I wonder if the problem is related to the lack of a PowerNap firmware addition that allows continued had disk function while sleeping on Laptops. Powernap is not available as yet on desktops.

On Bugzilla you may have noticed that the original bug report goes back to 2008.

Perhaps you have your idle timeout set quite long (mine is on just 10 minutes)? The problem originally was with the SB Server letting Macs go to sleep when the idle timer expires. This led third party plugin developers (notably Gordon Harris with ReallyPreventStandby) to step in. That plugin itself has not been ideal (on the Mac, repeatedly spawning a utility try and keep the Mac from sleeping) and Gordon has acknowledged limitations on this thread.

Before Mountain Lion, the behaviour (most of the time) was that once woken up from sleep by a Squeezebox the server would stay awake until the idle timeout. Now with ML it seems that if the Mac was already in idle sleep then it will not wait another idle timeout period. Also, the scheme used by ReallyPreventStandby no longer works.

So yes, more people are now noticing that LMS fails to tell OSX to stay awake while playing with Mountain Lion, but the fundamental problem has been around for a long time. Since OSX 10.6 developers have been given a simple way to indicate that the idle sleep setting should be ignored. Now with 10.8 this has become critical.

To see what iTunes does while playing run pmset -g in a command window.

[nonnoroger]

As I understand it, under ML hard drive activity does not prevent sleep.

Previously, it was *supposed* to prevent sleep, but this worked for some people and not for others.

And, of course, nowadays it is not just playing local media from the hard drive, but also BBC Radio and Spotify via the local server as with Triode's plugins.

[danco]

Yes I first found the issue with BBCiPlayer. But of course it also happens when playing tracks from a local library on an external drive.

Interestingly, the latest version of Get iPlayer Automator specifically states that on ML it prevents sleep while downloading.

As for ReallyPreventStandby, I have now followed up my earlier posts, and have a shell script to prevent standby and one to permit standby once the SB is idle. I haven't fully checked with Activity Monitor or the like, but I don't think my inhibit standby script does repeatedly spawn a process. The trick is, yo check whether a process (my Dummy application) is already running, and to do nothing if it is.

[nonnoroger]

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]

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?

[danco]

So, is this a simple change that we can make for ourselves, or does it require a modified plugin? If the latter, can you post your modification.

I would be prepared to try it, though my own solution seems to be working for me at the moment.

I have had no problems with WOL. Maybe my answer is not subject to the problem you report. But more likely that issue depends on the model of Mac that one has. I am using a 2007 iMac. Those of us who have more than one Mac (maybe even iPad/iPhone) could try WOL independent of Squeezeboxes.

I do agree that the best solution is for LMS to deal with the issue in its own code, but I don't see that we "will have to" set the assertions within LMS itself, when ReallyPreventStandby works, rather that it would be *much* neater.

The one advantage of my approach is that it does provide a double-clickable way of preventing sleep, whatever else is going on. That is something I find useful. For instance, at the moment I m expecting an instant message from a friend so like to have my Mac awake with display awake, so as to make it easy to check if there is a message. Power assertions would not be the way to go with Messages/iChat, since most of the time one does not need to keep the machine awake, it is just a personal preference. Another case where power assertions wouldn't work is VisualHub, which still works fine but is not being developed further, so we are stuck with it as it is.