jdwek wrote:
> Michael and Roger
> Is there a beta release I should be loading? I noticed the bug is
> listed as fixed. Or is the fix a part of the not yet released 7.8?
>
> Thanks
>
> Jerry
Hi Jerry
I suggest you refer to the thread at
http://forums.slimdevices.com/showthread.php?96514-Doe
Is there a beta release I should be loading? I noticed the bug is
listed as fixed. Or is the fix a part of the not yet released 7.8?
Yes, it's 7.8 only.
--
Michael
___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/
Michael and Roger
Is there a beta release I should be loading? I noticed the bug is
listed as fixed. Or is the fix a part of the not yet released 7.8?
Thanks
Jerry
jdwek's Profile: http://forums.slimdevices.com/member.p
Great. Would that approach allow you to tell when to start allowing
sleep again or would you still be relying on timers?
No. There's no such thing as a "clientidle" event. Something has to do the
bean counting. Which means we still need some timer counting down the
delay since the last activ
mherger wrote:
> >
> I'm currently working on some more event driven approach. Instead of
> listening to all possible events, it might be easier to catch changes to
>
> the lastActivityTime. That would be a rather simple change.
>
> --
>
> Michael
Great. Would that approach allow you to te
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
Thanks for the heads up - yes, I missed that one. You sometimes provide so
much information I miss the most important parts...
I'm curr
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 PreventSt
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
nonnoroger 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 i
Munroe wrote:
> Perhaps one could just move to a dedicated server for the Squeezebox
> library. I have had an awful time getting ML and before that Lion to
> work WOL since Snow Leopard. In my house, we just purchased a WD
> MyBookLive for streaming movies/photos etc, and apparently one can
> i
Perhaps one could just move to a dedicated server for the Squeezebox
library. I have had an awful time getting ML and before that Lion to
work WOL since Snow Leopard. In my house, we just purchased a WD
MyBookLive for streaming movies/photos etc, and apparently one can
install a Logitech Media S
epoch1970 wrote:
> Nevermind the logic.
> Just try to get an accurate player status right after wake from sleep.
> When the machine needs to re-hook to the network, SBS to refresh its
> data
>
> In the srvPowerControl thread I have posted a piece of perl code that
> asks for player status usin
Nevermind the logic.
Just try to get an accurate player status right after wake from sleep.
When the machine needs to re-hook to the network, SBS to refresh its
data
In the srvPowerControl thread I have posted a piece of perl code that
asks for player status using JSON. It was intended to check
epoch1970 wrote:
> You want to infer that the busy player was the wake-up reason. This is
> racy. This will not work reliably, I will bet on that.
It does not matter whether it was the wake up reason or not. If a SB is
busy there is no harm in LMS keeping the server awake by making a power
asser
You want to infer that the busy player was the wake-up reason. This is
racy. This will not work reliably, I will bet on that.
epoch1970's Profile: http://forums.slimdevices.com/member.php?userid=16711
View this thread: http
epoch1970 wrote:
> I've been reading the bug report discussion, and a few pages back on
> this thread. "What woke me up?" is a question that won't get answered in
> the general case. "Who woke me up?" is an almost impossible question to
> answer.
>
> What seems possible with the current machines
I've been reading the bug report discussion, and a few pages back on
this thread. "What woke me up?" is a question that won't get answered in
the general case. "Who woke me up?" is an almost impossible question.
What seems possible with the current machines is this: "I'm going down
". Things can
gharris999 wrote:
> But why? Are you saying that OS X, like WinXP, doesn't obey the system
> power management settings when woken via WOL? If OSX does obey those
> settings, then the system imposes its own grace period and LMS will
> behave like any other service...exactly what you're asking fo
nonnoroger wrote:
> I do want to keep the grace period if we were woken up by a user at an
> LMS client device.
>
>
> Michael Herger has an idea how it might be done and we are testing at
> the moment. See BugTrack for details.But why? Are you saying that OS X, like
> WinXP, doesn't obey the
gharris999 wrote:
> Then I really don't understand what you're suggesting. In a couple of
> threads now, you suggest that the resume 'grace period' should be
> dropped from ReallyPreventStandby. I just pointed out a way that could
> be done without breaking the fix for Windows XP and now you're
nonnoroger wrote:
> Well no. OSX Mountain Lion goes back to sleep too - intentionally,
> reliably, and I think correctly. That is why this whole discussion was
> raised again in the first place.Then I really don't understand what you're
> suggesting. In a couple of
threads now, you suggest that
gharris999 wrote:
> The original rationale for the 'grace period' after resume was to fix a
> specific problem with Windows XP. Many users (myself included) would
> see their systems go back into suspend 2 minutes after a WOL no mater
> what system power management settings they had configured.
nonnoroger wrote:
> I have been looking at (part of) the history of ReallyPreventStandby at
> http://bugs.slimdevices.com/show_bug.cgi?id=8520 and have a couple of
> questions (for Gordon and anyone else following who might remember the
> issues).
>
> Gordon, you said then:
>
> The version I ca
No the duet does not have a wired connection at all. It sits by the
coffee machine plugged into its little recharging station.
BTW thanks for caring for my penguins. At this point the last ten
penguins are standing on one foot
---
jdwek wrote:
> I had an interesting occurence today. I woke up and found my duet
> remote in the kitchen. I was able to play music using the duet. The
> response time was long but it worked. I tried doing the same with my
> remote on my iphone and ipad and it did not work. I alos used teh
>
I had an interesting occurence today. I woke up and found my duet
remote in the kitchen. I was able to play music using the duet. The
response time was long but it worked. I tried doing the same with my
remote on my iphone and ipad and it did not work. I alos used teh
squeezepad remote app on
I have been looking at (part of) the history of ReallyPreventStandby at
http://bugs.slimdevices.com/show_bug.cgi?id=8520 and have a couple of
questions (for Gordon and anyone else following who might remember the
issues).
Gordon, you said then:
The version I came up with makes PreventStandby wor
gharris999 wrote:
> I'm glad you guys are working this out. And I'm happy that
> ReallyPreventStandby, though somewhat long-in-the-tooth, still manages
> to serve some function!
Thanks Gordon. I hope you will still be in a position sometime to take a
look yourself at the change I have made. The
I'm glad you guys are working this out. And I'm happy that
ReallyPreventStandby, though somewhat long-in-the-tooth, still manages
to serve some function!
gharris999's Profile: http://forums.slimdevices.com/member.php?useri
You are right about the settings. I don't use Spotify, just local files
and BBC at present, so I'll see if I have any problems with that setting
unchecked.
danco's Profile: http://forums.slimdevices.com/member.php?userid=21
danco wrote:
> Very neat idea.
>
> I have run into one problem, that is probably the way
> ReallyPreventStandby works (but I never debugged enough previously to
> know about it).
>
> I listened to a program on BBC using BBC iPlayer. After a while I
> stopped it (but did not turn my SB off). I t
nonnoroger wrote:
> I am now happy enough with the fix to ReallyPreventStandby (please see
> earlier post for full testing instructions) that I am going to keep my
> system this way for now. If you choose to do the same, I strongly
> recommend that you get yourself your own copy of caffeinate for
nonnoroger wrote:
>
> 4. In the Plugins tab again, go to the Settings for
> ReallyPreventStandby. To reproduce my configuration choose:
>
> Allow standby after how many idle minutes? 3
> Prohibit standby if players are on? Checked
> Inhibit standby command: caffeinate -i
> Re-enable standby com
nonnoroger wrote:
> But that is not what happens with Mountain Lion. As I have explained in
> several posts. The idle period is only applied after interactive use.
> Once that has expired a WOL does not keep ML awake for another idle
> period. This is why we are trying to find a solution.
>
I
jdwek wrote:
> I am not at all a computer person so I doubt if this will help. I did
> happen to notice this on a different forum and wondered if it might be
> useful. It is a caffeinate command that targets the specific program
> SABnzbd specifically. Could not we do the same thing with LMS?
I am not at all a computer person so I doubt if this will help. I did
happen to notice this on a different forum and wondered if it might be
useful. It is a caffeinate command that targets the specific program
SABnzbd specifically. Could not we do the same thing with LMS?
caffeinate -i /Applic
Couple of thoughts on your solution.
The -i switch should not be necessary, as the default is to prevent idle
sleep.
For debugging purposes, caffeinate -di might be good. That prevents both
display sleep and idle sleep, which makes checking easier in step 14.
I've made your changes, but current
danco wrote:
> ... What I do not understand is why, after WOL has woken up a Mac, it
> would ever go to sleep before the idle period as set in Energy Saver.
But that is not what happens with Mountain Lion. As I have explained in
several posts. The idle period is only applied after interactive us
nonnoroger wrote:
> It is a simple change to the plugin that you can make for yourself once
> it is installed. See next post for the modification. But let me clarify
> once again. ReallyPreventStandby still relies on polling every 60
> seconds. There is an almost inevitable race condition that de
If you would like to try this out please follow these steps (first three
probably already done):
1. In the settings web page go to the Plugins tab. (I usually start the
web page with the Advanced Settings button in the LMS system preferences
pane)
2. Under additional repositories at the bottom a
danco wrote:
> 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.
>
It is a simple change to the plugin that you can make for yourself once
it is installed. See next post for the modification. But l
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
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
>
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 c
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
danco wrote:
> 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
jdwek wrote:
> 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
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.
danco's Profile: http://forums.slimdevices.com/me
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
Turns out that kIOPMAssertionTypePreventSystemSleep has been available
since OS X 10.7 (Lion).
See
http://developer.apple.com/library/mac///#/documentation/IOKit/Reference/IOPMLib_header_reference/Reference/reference.html
n
nonnoroger wrote:
> 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
danco wrote:
> 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
nonnoroger wrote:
> 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
> wo
Voted for it!!
Really this is something that Logitech should make a priority
jdwek's Profile: http://forums.slimdevices.com/member.php?userid=56876
View this thread: http://forums.slimdevices.com/showthread.php?t=95980
_
jdwek wrote:
> 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. G
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
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 pa
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 al
(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 bei
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
i
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 c
nonnoroger wrote:
> Gordon - I notice that usually a second caffeinate is invoked before the
> previous one times out. Is this intentional/designed? Is the 60 seconds
> a built-in period for the re-invocaction? Any ideas why I could not get
> it working as a toggle?
>
> By the way, I have my sys
danco wrote:
> I'm sure you know what's happening on your own machine.
>
> But I see that the Roaringapps compatibility table lists Caffeine as
> compatible with Mountain Lion. If it's not, maybe you should report it
> there.
>
> I've just installed ML on an external drive, not my main one, so
nonnoroger wrote:
> OSX Mountain Lion (ML) has an idle sleep policy that requires apps to
> set sleep assertions if they want to prevent sleep after the period set
> in Energy Saver - see for example
> http://arstechnica.com/apple/2012/07/os-x-10-8/18/. This means that
> utilities I relied on und
nonnoroger wrote:
>
> I will try it for a couple of days and then post again.
No need to wait a couple of days. My Mac Mini is still going to sleep
sometimes while LMS is playing to a SB (Touch). For a while
ReallyPreventStandby, invoking caffeinate, does prevent standby beyond
my system idle t
Well, it dawned on me that we should be able to invoke caffeinate as it
is from ReallyPreventStandby instead of Gordon's sleep-inhibit (although
I see from the source of this that it was also using assertions, but
differently from caffeinate and presumably not in a way that works under
Mountain Li
danco wrote:
> I don't have Mountain Lion yet, but I wonder if my old solution would
> work.
>
> There was a little program called Jiggler that prevented sleep by
> simulating a mouse movement every minute or so. I wrote a very simple
> shell script to start and quit Jiggler, and then I used Ser
I don't have Mountain Lion yet, but I wonder if my old solution would
work.
There was a little program called Jiggler that prevented sleep by
simulating a mouse movement every minute or so. I wrote a very simple
shell script to start and quit Jiggler, and then I used Server Power
Control to run t
gharris999 wrote:
> I'll be happy to look at the source for caffeinate and see if what it's
> doing could be incorporated into ReallyPreventStandby. But I don't have
> Mnt Lion yet and living on the wrong side of the digital divide means
> that it might be some time before I get it. Need to fin
nonnoroger wrote:
> OSX Mountain Lion (ML) has an idle sleep policy that requires apps to
> set sleep assertions if they want to prevent sleep after the period set
> in Energy Saver - see for example
> http://arstechnica.com/apple/2012/07/os-x-10-8/18/. This means that
> utilities I relied on und
OSX Mountain Lion (ML) has an idle sleep policy that requires apps to
set sleep assertions if they want to prevent sleep after the period set
in Energy Saver - see for example
http://arstechnica.com/apple/2012/07/os-x-10-8/18/. This means that
utilities I relied on under Lion - Caffeine and Really
71 matches
Mail list logo
