Re: [SlimDevices: Plugins] Announce: BBCiPlayer Plugin (UK only)

[nonnoroger]

Also getting a whole list of individual program(me)s after/before
Thursday.



nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=53229

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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-Does-LMS-work-on-Apple-OS-10-8-Mountain-Lion

Your choice of whether to go with the Beta or wait for the release.
Michael?



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

Re: [SlimDevices: Plugins] Announce: BBCiPlayer Plugin (UK only)

[nonnoroger]

Triode wrote: 
> Version 1.2.9 should hopefully fix this.

Which it does! Many thanks.



nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=53229

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 tell when to start allowing
sleep again or would you still be relying on timers?

Roger



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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
> install a Logitech Media Server on that via ssh in the Terminal.  
> 
> I haven't attempted it, as I am following some threads dealing with the
> sleep issue in MLion, but I am considering it a backup plan in case
> nothing else will work.  Likely means duplicating a music library on the
> network storage unit but it is an option if it works.  And for <$150 for
> 2TB, its not that cost prohibitive.

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. This is largely due to the 60 sec
polling approach that these plugins take. It is also an issue to tell
whether the WOL was due to user activity at a SB player or something
else in a way that does not slow down the plugin response.

Anyone interested in the details can look at recent contributions on
http://bugs.slimdevices.com/show_bug.cgi?id=8141



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 using JSON. It was intended to check for player
> status over mysqueezebox.com but it works also with a local server (or
> should with minimal change.) You are welcome to 'hack it'
> (http://forums.slimdevices.com/showthread.php?48521-Announce-Beta-version-of-SvrPowerControl&p=470590#post470590)
> and try it for yourself over random sleep/wake cycles and see how this
> fares. 
> 
> Anyway. I want to say that I am always glad to see people trying to make
> advances in LMS power management. And I hope your SB setup will bring
> you satisfaction in the end.

Many thanks - I will take a look.

As for the logic, it turns out that testing to see if we have just
resumed is something of a red-herring. If we have a test of whether a
client is busy that is all that matters.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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
assertion (as by pmset noidle). If no SB is busy, LMS had better not
prevent the server from promptly going back to sleep. If appropriate,
some other service will make the power assertion.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 is this: "I'm going down
> ". Things can be tried at that moment to
> ensure graceful wake-up. To do this the server (or an external helper)
> must hook up to the power management features of the OS. We're missing
> this part, IMHO.
> 
> (While I have 10.8 on one machine already I must admit I haven't powered
> it up yet to see how things have changed pm-wise… It's an MBA model
> 2010, SSD and wifi, could be a challenging test platform though. I don't
> have SBS installed on it.)

But we are not asking "what woke me up?" in general. We are asking "Is a
SB player busy?"



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 for.
> 
> Please provide a link to the bug, thanks.

The Computer Sleep period set in Energy Saver only applies after an
interactive user has stopped using keyboard or mouse. I think this is
probably the way OSX has always been meant to work. Now in Mountain Lion
it does this reliably and consistently.

If there is a WOL, since there has been no interactive use longer than
the sleep period, the system will soon go back to sleep unless a program
prevents sleep by setting the appropriate power assertion.

Sorry if this was not clear from earlier posts.

There is a new command in ML called caffeinate that is intended to allow
an interactive user to override the normal sleep period, for a specified
time, to run a specified command, or as long as caffeinate runs. This is
the program I suggested the use of by ReallyPreventStandby.

There is also the command "pmset noidle" that has been in OSX since 10.5
Leopard. This is the command that the trial version of PreventStandby is
using.

The Bug is the one I asked people to vote for on this thread - 8141.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 saying
> no.  I don't get it.

This goes back to me asking if we could tell whether it was SB activity
that woke up the Mac. You said that you could not tell from the WOL. I
agreed but thought that we might be able to tell from the state of the
connected SBs.

I do want to keep the grace period if we were woken up by a user at an
LMS client device.

I do not want to keep the grace period in any other case - LMS is just
one service running on the machine. There are lots of occasions when the
Mac is woken up that have nothing to do with LMS. The corresponding
services do work to see if they are needed. So should we.

Michael Herger has an idea how it might be done and we are testing at
the moment. See BugTrack for details.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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.  This problem
> was much discussed on forums at Microsoft and was difficult to debug
> because not every system exhibited this behavior.  There was a small
> chorus of complaints by windows XP SBS users that the stock
> PreventStandby plugin failed to prevent standby in this situation.  So I
> added the 'grace period' as a work-around in the stock PreventStandby
> plugin and ReallyPreventStandby inherited that code.

Yes, I noticed that when I looked up the original discussion on
Bugzilla

gharris999 wrote: 
> 
> Probably the proper thing to do is to test for the OS on resume and
> reset the counter to 0 only when the OS is windows.

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.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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
> squeezepad remote app on my ipad and at first it did not work and then
> it did but very slowly and in a limited way.  The computer monitor was
> still off.  
> Once I started using the computer all my remotes worked well.  So in my
> limited computer brain it appears that WOL seems to have worked somewhat
> using the duet remote but was unable to wake my imac up fully from
> sleep. 
> One more thought:  Mountain lion utilizes Power nap to allow background
> functions on laptops to work.  Does anyone know if that allows a laptop
> to stream continuously?
> 

Does the Duet have a wired connection to your network? WOL works
reliably over the wired network provided your Mac is configured to allow
Wake for Network Access in Energy Saver Preferences.

The iPhone and iPad definitely fo not have wired access. To wake-up the
Mac over the wireless network there needs to be a service Apple call
Wake on Demand available. It is supported by Apple's own Airport base
stations but needs a reconfiguration of your Mac that as far as I know
can only be done from the command line. Once done, it would also mean
that your MAc would probably be woken up more often by the base station.
In view of the below, let me know if you do want any more details!

I doubt very much if the Mac can stream without being fully awake but
the screen does not need to be on.

jdwek wrote: 
> Nonnoroger, thanks for your very polite reply to my last thread.  To a
> large extent alot of what you wrote goes over my head but I appreciate
> the explanation and your patience.  Unfortunately my brain is like the
> iceberg for the penguins.  All available ice crystals are taken up by
> standing penguins.  Any new info will cause another penguin to be
> launched off the iceberg ;)
> Thanks
> Jerry

We all get that feeling eventually but I have never heard it described
so imaginatively. I have moved some of the discussion of sleep issues
onto the Developer Forum. I fully inderstand why you would not want to
make the changes to the ReallyPreventStandby plugin yourself. It is much
more reliable though on Mountain Lion if done that way, I very much hope
that the developers will have an update soon that allows room for more
penguins.



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

Re: [SlimDevices: Plugins] Announce: Spotify Premium Plugin (Beta)

[nonnoroger]

Triode wrote: 
> I don't ship that CPAN module this is part of the server distribution. 
> I'll look at what I can do in my binary though.
> 
> You should be able to find it in the code shipped with the server - its
> in CPAN/Proc/Background/Unix.pm somewhere...  (not sure where will be
> installed on your machine though)
> 
> Edit: next binary will catch SIGQUIT and just exit - I think this avoids
> this.  PM me an email address and I will send you a binary in advance to
> prove this.

Done.

BTW CPAN shows Bug #41319 for Proc-Background: Sequence of signals from
Nov 2008!



nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=79706

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] Announce: Spotify Premium Plugin (Beta)

[nonnoroger]

Triode wrote: 
> Well this is a feature of CPAN's Proc::Background then which is used to
> start background processes for the server - this has the following code
> in it:
> 
> sub _die {
> my $self = shift;
> 
> # Try to kill the process with different signals.  Calling alive()
> will
> # collect the exit status of the program.
> SIGNAL: {
> foreach my $signal (qw(HUP QUIT INT KILL)) {
> my $count = 5;
> while ($count and $self->alive) {
> --$count;
> kill($signal, $self->{_os_obj});
> last SIGNAL unless $self->alive;
> sleep 1;
> }
> }
> }
> }
> 
> This is part of the server distribution, all I am doing is using that
> module.  I do trap HUP in spotifyd so that the process does not end if
> the terminal session which started it ends, which seems reasonable. 
> However the use of QUIT to kill something before trying INT is contary
> to what you are saying...  I've just checked the latest version of that
> module on CPAN and that code remains the same.

That's it then - they have the order wrong. I will not have been the
only one silently witnessing core dumps.

Could I ask that for the next release you either catch SIGQUIT and just
exit (or you could catch, ignore, and wait for the INT). Or else alter
the order in the version you use. Should I be able to locate where _die
is defined in the mean time? I could not find it when I looked before.

Very glad it is nothing more serious.

Many thanks.



nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=79706

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 work a little harder. 
When the timer code gets executed, it checks for the following states:
Players playing, players updating (firmware updates) the scanner running
*and it detects if the system has recently resumed from standby or
hibernation*.  If any of these conditions are met, the timer code zeros
a countup variable that otherwise gets incremented every minute. (Stars
mine.)

Which I can see from the code it still does:

if ( _hasResumed($currenttime) || _playersBusy() ||
Slim::Music::Import->stillScanning() ) {

$g{nHasBeenIdle} = 0;

(My change so far has been to remove the side-effect of calling
_hasResumed which was to enable sleep.)

I understand the reasons why it makes sense to have a grace period after
a SB has been turned on for the user to select what he or she wants to
play.

But the problem is with the current logic that we are imposing this
grace period on every wake of the system (OSX and Mountain Lion in
particular is my immediate concern). hat is not of much issue if the
grace period is less than the idle timeout and the machine has been
woken by an interactive user at the keyboard. But if it is a WOL from
some other device than a SB we should not be imposing the LMS grace
period.

I noticed this by looking at the ReallyPreventStandbylogs while my
system was being woken up by a WOL probe from an AppleTV.

I will have a go at fixing the logic tomorrow.



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

Re: [SlimDevices: Plugins] Announce: Spotify Premium Plugin (Beta)

[nonnoroger]

Triode wrote: 
> I don't see why this is logging a crash report as its saying the reason
> is receiving a quit signal - I would expect the application to close
> when it sees this.  Perhaps someone more familiar with OSX can comment?
Well no - any *nix uses the SIGQUIT signal to cause a "core" dump. It
was often generated interactively buy a developer typing ctrl-\ at the
foreground process to get a dump for debugging.

SIGINT is the signal that can be generated by ctrl-C at the keyboard and
normally causes a clean termination of a process - but it can be
"caught" by the receiving process to let it do some cleaning up before
exiting.

I turned logging to DEBUG for spotifyd and stopped LMS again. Nothing in
the spotify log, but the server log said:

[12-08-22 10:42:35.7588] Plugins::Spotify::Spotifyd::shutdownD (158)
killing spotifyd

In your SpotifyD.pm you have:

sub shutdownD {
my $class = shift;

if ($spotifydChecker) {
Slim::Utils::Timers::killSpecific($spotifydChecker);
$spotifydChecker = undef;
}

if ($spotifyd && $spotifyd->alive) {

$log->info("killing spotifyd");
$spotifyd->die;
}
}

Which presumably generated the log message. What is the effect of
$spotifyd->die;?



nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=79706

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] Announce: Spotify Premium Plugin (Beta)

[nonnoroger]

Hello Triode

This has been happening for a while but I thought I should post this now
it has happened again with your latest version. I stop LMS from the OSX
Preference Pane.

Top of crash report says:

Process: spotifyd [17095]
Path:/Users/USER/Library/Caches/*/spotifyd
Identifier:  spotifyd
Version: ???
Code Type:   X86-64 (Native)
Parent Process:  perl5.12 [17058]
User ID: 501

Date/Time:   2012-08-21 16:16:43.817 +0100
OS Version:  Mac OS X 10.8 (12A269)
Report Version:  10

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_CRASH (SIGQUIT)
Exception Codes: 0x, 0x

I still have some crash reports from before my move from Lion to
Mountain Lion.

All starts up fine again on restart.



nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=79706

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 call I deleted might have
been needed for some other case. Also the server log has some things
about deprecated calls. If you are happy with the change you might want
to release a an update. Happy to work with you on that off-line.

But yes - working well for me now - just the occasional slip back into
sleep on waking from an SB but I think that is due to caffeinate (the
prevent sleep command) not being called quickly enough.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 thought ReallyPreventStandby
> would now regard the SB as idle. However it seems not, I had to wait
> till PowerSave kicked in to turn the SB off. I'll have to check with an
> item from my own music library rather than the BBC.

When you followed my suggestions you will have set:

Prohibit standby if players are on? Checked

So ReallyPreventStandby is doing exactly what it was asked to do. You
could try setting it unchecked but I strongly suspect you will find that
your Mac will go to sleep while it is playing BBC iPlayer. That should
not matter a great deal as this plugin only needs LMS to get started.
BUT I have Triode's Spotify configured to Always Stream via the Helper
(to solve other problems). I very much doubt you will find that
ReallyPreventStandby really prevents standby while Spotify is playing
with this configuration.

That is why I keep Prohibit standby if players are on? Checked. It is a
simple and reliable condition that ReallyPreventStandby can check.

So yes - it is a good idea to have PowerSave configured.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 command: pkill caffeinate
> Inhibit is a toggle command: Checked
> 
> Then Apply the changes
> 
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 use just
by ReallyPreventStandby. This will prevent any other interactive uses of
caffeinate from being unexpectedly terminated after all you SB's are
turned off.

I find it easist to do this in a terminal window, but the following
could be done in Finder:

cd
pwd
mkdir bin
cp /usr/bin/caffeinate bin/lms-noidle

this sequence makes sure you are in your home directory (or folder),
prints (shows) the full pathname of that folder (should be /Users/USER
where I am assuming you are logged in as the user who installed LMS),
makes you a new directory (folder) called bin (for binary - if you
already have one you probably do not need any help from me), and then
takes a copy of caffeinate as lms-noidle and puts it in your own bin
directory.

Then, in the ReallyPreventStandby instructions quoted partly above use
lms-noidle instead of caffeinate:

Inhibit standby command: /Users/USER/bin/lms-noidle -i
Re-enable standby command: pkill lms-noidle

I have suggested that you place the copy of caffeinate outside the
ReallyPreventStandby folders so you will not lose it if installing or
re-installing the plugin.
You could instead try using the command that Gordon provides which is
/Users/USER/Library/Caches/Squeezebox/InstalledPlugins/Plugins/ReallyPreventStandby/bin/mac/sleep-inhibit
- especially if you want to try my fix and configuration on versions of
OSX before Mountain Lion that do not have caffeinate.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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?
> 
> caffeinate -i /Applications/SABnzbd.app/Contents/MacOS/SABnzbd &

Thanks jdwek but no. LMS runs continuously as a service. It is not run
as a command as and when you want to play some music. The S in LMS
stands for Server.

The usage of caffeinate in the example you found will prevent idle
timeouts for as long as SABnzbd runs. The & at the end of the command
means that caffeinate will do its work on SABnzbd "in the background" -
effectively meaning that the terminal command prompt will come back to
you straight away. Run the ps command then and you should see caffeinate
listed among your running processes. Type pmset -g to see that
caffeinate has turned off the idle timeout. The command fg will bring
caffeinate back into the foreground - you could then terminate it, and
the SABnzbd it has started, by typing ctrl C to interrupt it.

LMS should not require a great deal of computer background to use when
it works - it has failed as a product if it does. But unfortunately when
it goes wrong those who have the background seem to have to get involved
as Logitech often seem very slow to pick these things up themselves.
There is a priority system for dealing with bugs - hence my plea for
people to vote. Many thanks for doing so.

As caffeinate is likely to be used for other things apart from my test
fix, please see my next post regarding my steps for getting
ReallyPreventStandby to (mostly) work.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 use.
Once that has expired a WOL does not keep ML awake foranother idle
period. This is why we are trying to find a solution.

As I have also said before I think Apple have it right with ML. It is
now up to developers to use the tools properly, (And I do know about
legacy programs which will not be fixed but caffeinate and a
corresponding GUI will provide a solution for that.) Caffeinate is fine
for interactive use when the Mac is already awake, directly, or
indirectly from scripts, but to call after WOL will give us race
conditions in my view.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 add
http://srvrpowerctrl.googlecode.com/svn/beta.xml
This is the link to Gordon's plugins. I am sure he would want me to
remind you that this is still Beta code.

3. Apply the changes and then select ReallyPreventStandby from the list
of Gordon's plugins. Apply again.

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 command: pkill caffeinate
Inhibit is a toggle command: Checked

Then Apply the changes

5. Stop the LMS server from the preferences pane.

6. Go to /Users/USER/Library/Caches/Squeezebox/InstalledPlugins/Plugins
where USER is replaced with your login name.
To do this in the Finder you will need to hold down Alt while selecting
the Go menu.

7. Edit Plugin.pm - TextEdit should do. Note Gordon's Copyright Notice.
Find the definition of the subroutine _hasResumed. Comment out the
entire line _killInhibitCmd(); by putting a # in front (alt 3 on my
keyboard).
I suggest you also add a comment line explaining why.

8. Exit TextEdit, saving explicitly first if you want to. Under Mountain
Lion, TextEdit will already have saved the version at Open so you can
restore that.

9. Make sure all your SBs are off (not with power disconnected but with
the off button pressed, Radio, or selected Touch, which are the only
models I have (Four Touches). Restart LMS from the preferences pane.

10. Optional, but I suggest you do this during testing: Under the
Advanced Tab in the LMS Settings Web page, select the Advanced tab,
Logging, and set ReallyPreventStandby to Debug. Apply.

11. Let your Mac go to sleep by reaching its configured idle period
(Mine is set to 10 minutes). Hands off keyboard and mouse. We want to
see what happens when you turn on an SB.

12. Start some music playing on your SB from My Music.

13. See if the Mac stays out of standby - for at least a couple of
minutes or more. It should stay out of standby as long as at least one
SB is on.

14. Pause or stop playing and turn off all SBs as before. See if the Mac
stays active for the grace period (3 minutes in the settings above).

15. Once the Mac has gone back to sleep, go back and repeat fro step 12
a few times. We want to know how reliable you find ReallyPreventStandby
with these settings and my change.
Keep Hands off keyboard and mouse. 

16. After several cycles, go back to your mac screen/keyboard and take a
look at the LMS Server log in Console - if you set debugging above.

Please let us know how you get on

Many thanks

NonnoRoger



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 let me clarify
once again. ReallyPreventStandby still relies on polling every 60
seconds. There is an almost inevitable race condition that depends on
the precise timing of asynchronous events that leads in my testing to
the Mac occasionally going back to sleep after WOL before caffeinate has
set the power assertion. For similar reasons, it sometimes goes back to
sleep too early - ignoring the set grace period in the settings of
Really PreventStandby. I asked if others wanted to try it nevertheless
so we could get an idea of just how often this happens in practice.

danco wrote: 
> 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.
Sorry but again I seem to have failed to help you understand my point.
It is not an issue with WOL in general but with WOL from a Squeezebox
when ReallyPreventStandby is polling every 60 seconds. Hopefully, other
applications that use WOL will do what is necessary themselves. The
nature of the race condition will no doubt change depending on how many
cores the processor has. I run LMS on a late 2009 Mac Mini.

danco wrote: 
> 
> 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.
It is not just a question of neatness. It is only with LMS creating and
releasing its own power assertions that we will be able to reliably
avoid the race conditions explained above.

danco wrote: 
> 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.
Of course, I too would like Caffeine or something like it to work
reliably again (I have had no response from the developers). But that is
a different solution to a different problem



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 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'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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 and Spotify via the local server as with
Triode's plugins.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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
> 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'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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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

danco wrote: 
> 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.

danco wrote: 
> 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.

danco wrote: 
> 
> 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.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 I'll
> check some time what result I get.

Hmmm. I had hoped I knew what was happening on my own machine. But
prompted by your post I have just tried it again to find it did prevent
sleep beyond my set idle timer.

It seems that I am not the only one to report it failing to prevent
sleep though - see the replies to this post:
http://hints.macworld.com/article.php?story=20120801003744629.

I have emailed the developers but have not had a reply. I will hold off
for things to clarify before contacting Roaringapps.

Note though that caffeine is not useful for LMS use as it also stops the
screen from blanking (when it works!)



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 timer. But sometimes it just goes to sleep.

I strongly suspect that this is a glitch that comes with the repeated
calls of caffeinate. Caffeinate -i called directly from the command line
has never yet allowed sleep.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 Lion).

ReallyPreventStandby has these settings:

Allow standby after how many idle minutes?
Prohibit standby if players are on?
Inhibit standby command
Re-enable standby command
Inhibit is a toggle command

Under OSX, by default, the inhibit command is set to sleep-inhibit with
a period of 60 seconds. There is no re-enable command and the inhibit
command is not a toggle (meaning it gets called periodically - I guess
every 60 seconds or thereabouts).

My first try was to set these as:  /us/bin/caffeinate -i (which creates
an assertion to prevent the system from idle sleeping), pkill
caffeinate, and command is a toggle. But found that caffeinate was not
getting invoked (I do not know why).

So instead I am now using: /usr/bin/caffeinate -i -t 60 (create the
assertion for 60 seconds), no re-enable command, and inhibit is not a
toggle.

This now seems to be working! Well, after about 30 minutes of listening
I did get the system going into standby while playing once. Just
wondering if this was due to one invocation of caffeinate terminating
before a new one is started.

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 system sleep time set to 10 minutes. I am
currently running with ReallyPreventStandby set to preventing standby if
players are on - when I had the system going into standby while playing
this setting was off.

I will try it for a couple of days and then post again.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 Server Power
> Control to run these scripts at the relevant moments.

Thanks for the reminder about Jiggler Danco.

I have now downloaded 1.4 and tried it under Mountain Lion (bypassing
the warning that it does not have a developer signature). ML really does
have an aggressive sleep policy as Jiggler jiggles but does not prevent
sleep.

I would have been happy to use it as an interim solution if it had
worked, but I remember now why I started using Caffeine - those mouse
jiggles are disconcerting for anyone else in the family who comes to use
my Mac Mini while Jiggler is running.

The way ahead with ML does seem to be with the assertions.



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

Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 find someplace in
> town where I can set up my mac mini and download it.

Good luck with that and very many thanks for picking this one up.



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

[SlimDevices: Plugins] OSX Mountain Lion sleep issues

[nonnoroger]

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 ReallyPreventStandby
plugin for LMS no longer work.

There is a new command line utility in ML that might give some pointers
to a way forward:

caffeinate – prevent the system from sleeping on behalf of a utility
This allows you to either directly prevent your Mac from falling asleep
for a specific period of time (e.g. an hour):

caffeinate -u -t 3600

or allows a command to run for a prolonged period without the automatic
(and, since 10.8, rather aggressive) sleep function kicking in

caffeinate -s any-long-running-command -with arguments

The source of caffeinated seems to be here:
http://opensource.apple.com/source/PowerManagement/PowerManagement-271.25.8/

Has anyone else had sleep issues under ML running LMS (I am running
7.7.2)?

Does anyone who knows the system better than me have any suggestions for
a way forward?

Seems like these new assertions could finally give a reliable solution
to LMS sleep issues under OSX if they could be incorporated somehow. I
do not think it will work just for ReallyPreventStandby to call
caffeinate as the command just hangs until interrupted if called as
caffeinate -i.

All help much appreciated.



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

Re: [SlimDevices: Plugins] UK: BBC HD Sound - BBCiPlayer Support

[nonnoroger]

Triode;586009 Wrote: 
> The BBC has announced trials of 320k AAC streams which they are calling
> "HD Sound".  This is being supported for specific events on Radio 2 and
> will become the standard for Radio 3 streaming.
> 
> ...
> 
> To try please install the latest version of the BBCiPlayer plugin, and
> navigate to the "Special Events" menu at the bottom of BBCiPlayer menu
> lists.  
> 

Many thanks Triode for your continued excellent support and development
of this plugin.

Just a suggestion - would you please consider taking the opportunity of
introducing this new menu choice to move to have just three options at
this level:

Listen Live
Listen Again
Special Events

I think this would make navigation easier by a worthwhile amount by
making the menu structure more consistent.

Thanks again

NonnoRoger


-- 
nonnoroger

nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=82967

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] Announce: BBCiPlayer Plugin (UK only)

[nonnoroger]

... many thanks for the quick response!


-- 
nonnoroger

nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=53229

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] Announce: BBCiPlayer Plugin (UK only)

[nonnoroger]

bpa;538397 Wrote: 
> It is hard to give help without more details other than "not working"
> 
> Do you get all "Listen Again" menus ?
> Are you using AAC or WMA streams ?
> Have you tried all live streams including little used ones such as R4LW
> ?
> Are you in the UK or not ?

Those are troubleshooting questions - not problem threads. The closest
one I could find seemed to be an issue with Windows 7 and Explorer 8.


-- 
nonnoroger

nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=53229

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] Announce: BBCiPlayer Plugin (UK only)

[nonnoroger]

bpa;538363 Wrote: 
> There are lots of users finding problems with internet live streams so
> it looks like a BBC problem.
> 
> See BBC iPlayer Message Boards
> http://www.bbc.co.uk/dna/mbiplayer/NF13735684

I had already looked there and decided that the problems discussed were
not the same as we are experiencing. Which thread in particular are you
thinking of?


-- 
nonnoroger

nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=53229

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] Announce: BBCiPlayer Plugin (UK only)

[nonnoroger]

As SB is not on the list of supported iPlayer devices, is the following
an indication of our current problems with AAC live streams?

http://www.bbc.co.uk/blogs/bbcinternet/2010/03/bbc_iplayer_content_protection.html


-- 
nonnoroger

nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=53229

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] Announce: BBCiPlayer Plugin (UK only)

[nonnoroger]

Triode;537679 Wrote: 
> So I think the wma streams are working, but rtmp ones are not.  Suggest
> people select "prefer wma" for the moment.
> 
> I will look at in more detail later this week.

As reported on my first post on the AAC resets, when I set the wma
preferred option there are no connection errors but I get no sound.
This is with SBS 7.5 on a Mac Mini with both SB Radio and SP Touch
players.

For now, resorting to Local | London | All Stations | BBC Radio 4 93.5


-- 
nonnoroger

nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=53229

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] Announce: BBCiPlayer Plugin (UK only)

[nonnoroger]

Suddenly, from around lunch time today, 19th April, I have been getting
this error when connecting to live BBC streams using v1.1.4.

Using Touch and Radio.

Listen again works fine.

Enabling prefer wma (which I do not) seems to connect but gives no
sound.

Anyone else experiencing this?

Thanks 


-- 
nonnoroger

nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=53229

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] Announce: BBCiPlayer Plugin (UK only)

[nonnoroger]

Suddenly, from around lunch time today, 19th April, I have been getting
this error when connecting to live BBC streams using v1.1.4.

Using Touch and Radio.

Listen again works fine.

Enabling prefer wma (which I do not) seems to connect but gives no
sound.

Anyone else experiencing this?

Thanks 


-- 
nonnoroger

nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=53229

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] scpowertool --hibernate not working

[nonnoroger]

nonnoroger;505329 Wrote: 
> ... I need more than a forced standby when not playing as my Mac Mini is
> also used for EyeTV.
> 
> 

And thanks to help from Draco elsewhere, now realise that I can use the
custom commands to get the extra action I need.


-- 
nonnoroger

nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=73443

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] Announce: Beta version of SvrPowerControl

[nonnoroger]

Many thanks - I just had not twigged what those custom actions were for.


-- 
nonnoroger

nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=48521

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] scpowertool --hibernate not working

[nonnoroger]

gharris999;503653 Wrote: 
> Fair enough.  I'll try to resist the urge to tinker with what's
> working.
> 
> Would you guys (and anyone else) care to comment on the following?
> 
> My SrvrPowerCtrl priorities at the moment are:
> 
> 1). Move all the "optional action to take while not idle" support out
> of SrvrPowerCtrl and into a beefed up mac+linux+windows friendly
> PreventStandby plugin.
> 
> 2). Make the " to mysqueezebox.com" more generic so that one could
> pick other alternate servers (i.e. a TinySC) to "" to.
> 
> ...
> 
> 

I would find PreventStandby for OSX really helpful - I have so far
failed to achieve what I need with SrvrPowerCtrl (turn Caffeine on when
playing, turn it off when nothing playing). I need more than a forced
standby when not playing as my Mac Mini is also used for EyeTV.

Many thanks ...


-- 
nonnoroger

nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=73443

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Re: [SlimDevices: Plugins] Announce: Beta version of SvrPowerControl

[nonnoroger]

danco;502289 Wrote: 
> OK. Run Caffeine (so it is in your menu bar - you could have it run at
> login) and then to turn it on or off you need a shell script that calls
> an Applescript.
> 
> The shell script needed is
> 
> #! /bin/bash
> osascript -e 'tell application "Caffeine" to turn on'
> 
> 
> This can be written in any convenient text editor. But you need to make
> sure that the quotes are not smart quotes, and that the text is saved as
> plain text not rich text (and that line endings are Unix endings, which
> is usually automatic).
> 
> Once the script has been saved, you need to make it open with Terminal
> (easy by using Get Info from the Finder).
> 
> And then you need to make it executable. To do that, open Terminal,
> type
> 
> chmod a+x (and a space) and then drag the file into the Terminal
> window. By a bit of Mac magic this automatically types in the full path
> to the file, so you don't need to type it manually.
> Press return, and the file should now be executable by anyone. You can
> check this by double-clicking and seeing what happens.
> 
> Similar shell script to turn Caffeine off.
> 
> The first line of the shell script just identifies what shell you are
> using. Then the osascript command is an instruction to run an
> Applescript. the -e flag says that the bit between quotes is the text of
> one line of an Applescript. If you had a two-line Applescript you would
> need to write osascript -e 'line1' -e 'line2' and so on for more lines.
> For a long Applescript, one would do best to save it as a script file,
> and call it by osascript scriptfile. 
> 
> Ask me if you need more help. I'm by no means an expert as regards
> Applescript, but short scripts are usually easy to write and understand.

Experiencing the same sleep problems with OSX 10.6.2 and SBS while
players are active, I am trying out your solution - many thanks for the
detailed help.

But I cannot see an option to run a script with svsPowerCtrl when
players become idle.
The only options under Idle Player Monitor are to shutdown, restart,
suspend, hibernate etc.

I have installed the beta version as recommended for SBS 7.4.1.

What am I missing!?


-- 
nonnoroger

nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=48521

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

[SlimDevices: Plugins] Podcast Player and Squeezeslave

[nonnoroger]

Squeezebox Server 7.4.1 on OS X Snow Leopard
Squeezebox Radio - Podcast Player works fine
Squeezebox Controller - Also works fine

I am using Squeezeslave on the Mac Mini hosting the server as this is
the only software player that I have found that lets me:
1. Play 96/24 files
2. Select the output device on the Mac Mini (I use a M2Tech HiFace)
3. Synchronize with the hardware players

I control Squeezslave through the Controller or through SqueezePlay and
most things work just fine - MyMusic albums etc.

I can access the Podcast Player on Squeezslave as normal and select my
configured podcasts which play fine on the Radio and Controller. Now
Playing claims the podcasts are playing.

Only problem is that they are in fact not playing - no sound.

I would be very grateful for any pointers!


-- 
nonnoroger

nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581
View this thread: http://forums.slimdevices.com/showthread.php?t=73525

___
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins