OSX Mountain Lion sleep issues

[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.

Lately, I've been giving SrvrPowerCtrl a little more attention. The next version to hit my beta repo will include a feature to check for active login sessions on both Linux and OSX and optionally inhibit power saving when it sees one. Could that work for you? Could you train yourself and family members to always remember to logout when finished using the Mac? Under this scenario, you'd disable all or most of the OS X power management features and let SrvrPowerCtrl take care of business.

Many thanks for clarifying the position Gordon. That might explain a few things.

But sadly no - logging out and back in is not going to be a realistic option in our case.

Perhaps I should be beating at the Logitech's door and the LMS development team on this one.

Thanks again.

[danco]

I haven't tested this yet, and I'm not experienced with scripting. But I think the following or something like it would work under Server Power Control.

1. Create a program that does very little. The Applescript

delay 10

saved as a stay-open application would do (stay open is important). Give it a name such as Waiter (perhaps better would be something more complicated such as MyPersonalWaiter in case Waiter is part of the name of some other process).

2. Now create a shell script whose active content is

if [ $(ps -ax | grep -c [: print:]*Waiter) = 1 ]
> then
>open -g pathtoWaiter.app
>caffeinate pathtoWaiter.app
fi

where pathtoWaiter.app os the full path to the application. (I had to put in a space between : and p else it would have come out as a smiley)

The logic is as follows

The $( ) bit counts the number of running processes containing the word Waiter. There will always be one (that is, if these were Terminal lines, not sure if that also applies as a shell script) because the actual grep message provides one such process, but more than one if Waiter is running. So the condition holds only when Waiter is not running. If Waiter is already running nothing happens

At that point Waiter gets opened in the background and caffeinate prevents sleep while Waiter is running.

We should then be able to use this as the shell script for ServerPowerControl to run. Of course, the complicated first line is just to ensure that caffeinate is only run once, because of some issues mentioned earlier in the thread which may not apply in this use.

One advantage of this script is that it can be used to prevent sleep whenever we want, not just for LMS issues.

I'll experiment further, but better coders than me might like to try themselves.

[danco]

(Later) I've been doing a bit of further investigating. So far I have not been able to get caffeinate to work on an application, it keeps coming up with "permission denied". I find someone on the Apple Support Community forums with the same problem, so it seems to be a matter of some usage not being documented properly.

[jdwek]

I posted elsewhere here that my upgrade to mountain lion now no longer allows continuous streaming. I also suspected it was a sleep issue and it seems to be confirmed here. I did not have any issues with Lion and I had no extraneous application running in the background. Glad to see I am not alone here.

[danco]

I'm getting further into things.

I'm not sure if the ps -ax bit needs = 1 or = 0. I think it may be 1 when run from the terminal but 0 when part of a shell script.

You can't use caffeinate on a Mac application, only on a Unix command.

So the caffeinate line needs to be

caffeinate -i open -W path to Waiter.app

I have seen suggested that it should be open -W -a but I don't know why this should be. It may not apply in this case. The -W is important, as caffeinate only stops sleep as long as open is running, and without the -W this just opens the application and is then finished, while with -W open remains active until the application is quit.

One can perhaps tidy up the script with a parameter to put Waiter into the background (I think it is -g) plus a line (using osascript -e to call an Applescript) to put Terminal into the background.

It looks to me as though Really Prevent Standby itself would work using a suitable shell script along those lines to prevent standby rather than the default option.

I'll be happy to test if Gordon or anyone want to work it out further, or I might find the time to try it myself, now that I know how to use caffeinate.

[dweezil]

Interesting thread.

I have LMS on ML. When I have the ML machine set to sleep after 30 mins I can wake it up when starting one of the SB3s or Touch on the same network. I can also wake it up by sending a WOL signal when on the same network.

However I cannot get it to wake up, even if I sent a WOL when connecting over the internet.

So I've had to set the sleep option to never on ML :-(

[nonnoroger]

I posted elsewhere here that my upgrade to mountain lion now no longer allows continuous streaming. I also suspected it was a sleep issue and it seems to be confirmed here. I did not have any issues with Lion and I had no extraneous application running in the background. Glad to see I am not alone here.

It is about time that this issue was solved by Logitech. Please vote for http://bugs.slimdevices.com/show_bug.cgi?id=8141 as the third party attempted fixes are now tenuous so say the least.

Many many thanks to those of you who have been working to put together a workaround but I feel it needs to be sorted by Logitech.

[jdwek]

Voted for it!!

Really this is something that Logitech should make a priority

[danco]

It is about time that this issue was solved by Logitech. Please vote for http://bugs.slimdevices.com/show_bug.cgi?id=8141 as the third party attempted fixes are now tenuous so say the least.

Many many thanks to those of you who have been working to put together a workaround but I feel it needs to be sorted by Logitech.

I think you are a bit hard on Logitech. Mountain Lion introduced a new sleep policy (hard drive activity is ignored in resetting the sleep timer, only keyboard or mouse activity counts) that might not have made it into the final version of ML, so it wasn't really something to concentrate on. And ML has been out for less than a month.

Also, it is primarily an Apple issue, as any program that runs for a long time without human interaction (large downloads, video conversion, etc) gets caught.

If you look at the Mountain Lion section of Apple support community, the thread "help with caffeinate", you will find, as soon as I have time to put it up, instructions on how to write your own script to keep a Mac awake. Someone else will need to write a simple program to put this in the menu bar, in the way that Caffeine did.

I know a fair bit about this kind of problem, because of the reverse issue. My Mac running Snow Leopard refuses to go to sleep according to the Energy Saver settings. That got solved by using a third party sleep timer, but those were not reset by hard drive activity. So I had to use Jiggler or Caffeine to keep the Mac awake when I needed to (or Really Prevent Standby or Sever Power Control for Squeezebox use).

[nonnoroger]

I think you are a bit hard on Logitech. Mountain Lion introduced a new sleep policy (hard drive activity is ignored in resetting the sleep timer, only keyboard or mouse activity counts) that might not have made it into the final version of ML, so it wasn't really something to concentrate on. And ML has been out for less than a month.

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

Also, it is primarily an Apple issue, as any program that runs for a long time without human interaction (large downloads, video conversion, etc) gets caught.

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.

If you look at the Mountain Lion section of Apple support community, the thread "help with caffeinate", you will find, as soon as I have time to put it up, instructions on how to write your own script to keep a Mac awake. Someone else will need to write a simple program to put this in the menu bar, in the way that Caffeine did.

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.

I know a fair bit about this kind of problem, because of the reverse issue. My Mac running Snow Leopard refuses to go to sleep according to the Energy Saver settings. That got solved by using a third party sleep timer, but those were not reset by hard drive activity. So I had to use Jiggler or Caffeine to keep the Mac awake when I needed to (or Really Prevent Standby or Sever Power Control for Squeezebox use).

Me too. Exactly. 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.

Please vote for http://bugs.slimdevices.com/show_bug.cgi?id=8141 - the caffeinate source code I point to was intended as a possible model for developers to use in their own Apps. I did not envisage caffeinate itself being called.