Bugzilla – Bug 15457
Music before Alarm
Last modified: 2010-01-11 15:33:42 UTC
Squeezebox Radio connected wirelessly to a PC which sleeps after 20 minutes of inactivity. The alarm is set to 7.40 - at this time the radio plays at full volume what I presume is an internal file of a piece of music - not the playlist or volume that the alarm specifies. I turn this off using the power button (the screen says 'Alarm off' - at which time the correct playlist will start at the correct volume. I would think that this is happening as the WOL command is only sent at the same time as the alarm is supposed to go off - meaning that the server is unavailable as it hasn't been woken. So what is required is that the WOL command is sent 5 minutes or so before the alarm to ensure that the server is awake.
Why not WOL 10 minutes before alarm event like the boom does. You now how to do this.
Is it possible to set this then? Please tell me how?
(In reply to comment #2) > Is it possible to set this then? Please tell me how? My comment was meant for logitech, they now how to write software that does this. Nothing we can adjust ourself .
I'm very close to checking in a new version of the applet that handles the alarm on the Squeezebox Radio. FYI, I've added code to send a WOL packet 10 minutes before the alarm is due. Will require testing after checking it in, but the code itself is pretty simple. 10 minutes before the next expected alarm, send a WOL to the server...
== Auto-comment from SVN commit #8312 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8312 == Bug: 14870 Fixed Bug: 15457 Description: first checkin of merged code that includes Marc's code to defensively fire the fallback when things go bad and many other changes made by me -- include a sending of a WOL packet 10 mins before next configured alarm -- alarm window now has an EVENT_WINDOW_POP listener that resets the self.alarmInProgress value when the window hides. This effectively ties resetting of state variables to the popup window while allowing events to bubble up the event handler (i.e., return EVENT_UNUSED on callback actions) -- for now the sledgehammer method is only called by the decodePollTimer and not by the misc notification methods. My hope is that's what we can eventually settle on.