Bugzilla – Bug 15663
Radio doesn't wake up SBS via WOL early enough to get the server up in time
Last modified: 2012-03-05 08:21:02 UTC
Hi, I encounter the following -reproducable- issue with my SBS 7.4.2.30049 (PC, win7x64) in combination with the SB Radio: - Setting up an alarm works just fine via SBS or on the radio. I set either a playlist or internet radio as an alarm sound. - the alarm goes off just fine if the SBS is still on and not in standby mode. HOWEVER, if the SBS is in standby mode, - the radio wakes up the server via Wake-On-LAN to the time that the alarm should go off - the server doesn't wake up quickly enough / it takes too long to wake up - the radio only plays a beep sound instead of the preset alarm sound. I've read a few posts in the forum stating that the SBS should be woken up 10minutes in advance to an alarm which would be just perfect. In my case, this does definitely not work correctly (in combination with the SB Radio). Thanks for fixing and implementing the WOL prior to the alarm time in 7.4.2 final in advance!
*** This bug has been confirmed by popular vote. ***
*** Bug 15880 has been marked as a duplicate of this bug. ***
Actually Ben implemented a WOL-feature for the Radio shortly before 7.4.2 was released. You can find the code in the AlarmSnoozeApplet. Anyway neither me (nor other users, see bug #15880) are able to see a WOL package with a network sniffer, so there is something broken with WOL on the Radio.
7.4.x milestone is in the past
(In reply to comment #5) > 7.4.x milestone is in the past This bug still exists in the 7.5 builds!!
I have only just figured out what my long standing, extremely annoying (did I say extremely?... as in the only reason I bought the squeezebox boom was for the alarm and it doesn't work properly)! Turned out that my NAS has quite a large delay to spin up the disks in the morning and results in (at best) the backup alarm going, or at worst (no sound at all). So after experimenting with leaving the disks running the alarm actually works consistently every time. So after fretting that no-one's going to allow a timeout to be as long as I need I find that it is meant to pre-empt the server by a factor of 10 minutes. Awesome! I would point out that I am only running 7.3.3 of the server since Sabayon/Gentoo have not updated that yet, so perhaps my problem is fixed in a later release, but it sounds like it's not.
it's not but no dev seems to care :-(
For the SqueezeBox-Boom this is working - sending a WOL to the last known SB-server 10min ahead of an alarm (at least my Boom with 7.4). This is a Radio-only bug.
... and it keeps on in the 7.6 builds. The issue is still existing :-(.
oh man what da hell is this
Ben notes that the WOL packet is sent out 10 minutes in advance. Speculation about whether this is related to our various alarm Time Zone issues.
What means 10 minutes in advance does this mean 20 minutes before alarm? I haven't seem any WOL packet at all for my Squeezeradio.
Ben says he has an idea how to fix it, and Steven says he can easily test it.
ah OK - sorry - we all hope for a fix soon. It would be also great if it would be possible to set the pre wakeup time. For me 10 minutes seems to be too much. A lot of devices go back to sleep after 5 minutes of inactivity. Also there are def. no devices which need 10 minutes to wakeup.
== Auto-comment from SVN commit #8686 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=8686 == Fixed Bug: 15663 Bug: 15901 Description: send WOL packet with 5 mins lead time before alarm (or immediately as a best effort if alarm time is < 5 mins away) partial fix for bug 15901, add window listener for pause button that stops alarm tone, whether fallback or server-based
Ben, could you please confirm that you saw a WOL at least once with a network sniffer ? I'm pretty sure the code before your change should have sent a WOL as well, my reasoning: When the applet calls init() you will run through _startTimer which also in 7.5 set up a WOL (though 10minutes ahead). Nevertheless I couldn't see a WOL when setting an alarm 15minutes ahead. By the way: your new code to setup the WOL timer is useless (I think), as _startServer is still called after and will set the WOL-timer 10minutes before alarm time (thus overriding the 5 minutes ?). Don't know if I'm right though - these writing is just from code-review not from actually trying it out.
Stefan, good catch, you are correct. I don't have a WOL setup-- this bug is in QA's hands to analyze (I've been chatting with them today on it, so they are not in the dark) On second inspection, I agree with you that my code is useless, since _startTimer does the job of setting the countdown for the WOL timer. I'll revert and reopen...at this revelation I'm unclear as to why the bug is occurring. One thing I might try is to bring the WOL lead time down to 5 minutes, but I don't have a lot of confidence that's the root of whatever is being seen here.
== Auto-comment from SVN commit #8689 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=8689 == Bug: 15663 Description: revert previous WOL bug checkin, as Stefan pointed out correctly that adjusting the countdown to the timer in init() was a useless change change the lead time for the WOL packet from 10 minutes to 5 minutes, in hopes this helps the situation
This bug is now going to QA for two purposes: 1. to see if the bug can be reproduced 2. to sniff for a WOL packet at 5 mins before a configured alarm
== Auto-comment from SVN commit #8690 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=8690 == Bug: 15663 Description: typo fix-- timer for WOL needs to be sleepMSecs - wolLeadTime
As the WOL-code looked good even in 7.4.2 I personally didn't trust ---- self.server:wakeOnLan() ---- as that is the only thing where I don't know the code (and I never trust methods based on their names *g*). That being said I want to repeat that I did my WOL-tests just once and could have made an error (though I double checked and could see WOL from the Boom back then). So its a good idea to have QA prove at least once that they see I WOL from the radio 5 minutes before an alarm - or not. AlarmSnoozeCode looks code ... if there's no WOL then 'self.server:wakeOnLan()' is to blame.
(In reply to comment #15) > It would be also great if it would > be possible to set the pre wakeup time. For me 10 minutes seems to be too much. I fully agree with Stefan... a setting would be the best option for all alarm users. I will be able to test with the latest nightlies at the end of the week.... but I definetely can confirm that in the releases so far no wake-up on lan was initiated by the SB Radio, even in 7.6 builds. Thnaks for trying and fixing this. Seems that if I read all your comments that a fix is not far away... :-)
Ben, this still does not seem to be working. I set an alarm out 20 minutes or so a few times. The wol event does not appear to be happening 5 minutes before the alarm is set to go off. However the wol event still goes out when the alarm actually goes off waking my notebook in the process.
I neglected to mention this was with baby 7.5.1 r8697 and server 7.5.1 r30561.
Is there any progress regarding this? It looked so close to be fixed ... Michael
at the moment sadly still no fix
(In reply to comment #27) > at the moment sadly still no fix Has anyone tested with the battery accessory? I have found that if the Radio had been auto-shut OFF, while it will be properly auto-turned ON at the scheduled alarm time, if the server is down (i.e. power failure), that the back-up alarm will not sound (however, if the alarm is within 20 minutes of a power failure and the Radio does not auto-shut OFF, the backup alarm will sound)
How is the fix for this going on? I've now buyed my Logitech Radio 4 month ago and i'm still unable to use it - as i only wanted it for alarm stuff.
Created attachment 6854 [details] proposed fix for WOL bug self.server in AlarmSnoozeApplet was being set not only incorrectly but in the wrong place. correctly set self.server in notify_playerConnected() when the local player sends playerConnected message. add some extra debug for WOL in statusPoller (note: debug logging disabled by default) I've personally confirmed this patch properly sends a WOL packet 5 minutes before alarm time.
Thanks a lot. Is there a guide how to apply this patch? Or will it be in the next nightly snapshot?
== Auto-comment from SVN commit #8785 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=8785 == Fixed Bug: 15663 Description: in AlarmSnoozeApplet, self.server was being erroneously set to mysb.com regardless of which server the player was actually connected to. Move the setting of self.server into the notify_playerConnected() method, and only set it for the notification for the local player add more logging options for debugging WOL issues
Stefan(s), QA will need to qualify the firmware before it's pushed out to beta users. I believe that's happening today though...when it gets pushed out, look for the fix in any 7.5.1 firmware >= r8785.
(In reply to comment #32) > == Auto-comment from SVN commit #8785 to the jive repo by bklaas == > == http://svn.slimdevices.com/jive?view=revision&revision=8785 == > > Fixed Bug: 15663 > Description: in AlarmSnoozeApplet, self.server was being erroneously set to > mysb.com regardless of which server the player was actually connected to. > Move the setting of self.server into the notify_playerConnected() method, and > only set it for the notification for the local player > add more logging options for debugging WOL issues Has this been tested against an alarm on a SB Radio on Battery power if there is no network (i.e., power failure) -- WIll the backup alarm sound? Tony
Tony, this fix has nothing to do with what you are asking about, but what you are asking for should work and has been tested. A battery powered radio that experiences a power outtage is coded to wake itself up a few minutes before the alarm. This is unrelated to WOL (which if the power is still off will do nothing to wakeup a powerless server) the (client-side) backup alarm will sound since the network will be gone
(In reply to comment #35) > Tony, this fix has nothing to do with what you are asking about, but what you > are asking for should work and has been tested. > > A battery powered radio that experiences a power outtage is coded to wake > itself up a few minutes before the alarm. This is unrelated to WOL (which if > the power is still off will do nothing to wakeup a powerless server) > > the (client-side) backup alarm will sound since the network will be gone Yes, the SB Radio on battery that was shut down to conserve the battery does wake-up, however, the back-up alarm does not sound. (If the alarm is within 20 min and the Radio does not shut-down, the b/u alarm does sound). Seems to be an issue with the back-up alarm when the SB Radio wakes from sleep and there is no network to connect to. Can you do me a favor a see if you get the same result if you power-down your network with the SB Radio on battery. This is needed to assure an alarm during a power failure.
could you please open a new bug-report for this separate issue ?
(In reply to comment #37) > could you please open a new bug-report for this separate issue ? I did, but it has not been assigned. Please see 16230. Can you please test this bug and confirm if you agree. Thanks, Tony
@Ben Klaas regarding firmware and testing. Does SqueezeboxServer-7.5.1-30796.exe include this fix / the new firmware?
We don't bundle firmware inside SBS. The mechanism is that whatever SBS version you have (in this case, 7.5.1) checks our servers for the most current version of 7.5.1 firmware available. If it's a mismatch for what's in SBS's update cache, or if there isn't anything yet in the update cache, SBS downloads the firmware. After it's downloaded, a notification gets sent out to connected players that version X of the firmware is available. The check for new firmware by SBS happens every 12 hours, or immediately server restart. Looking at our update servers, r8785 is now available.
> Looking at our update servers, r8785 is now available. Correction: we have a server problem-- [10-05-20 09:38:29.2081] Slim::Utils::Firmware::downloadAsyncError (557) Warning: Firmware: Failed to download http://update.mysqueezebox.com/update/firmware/7.5.1/baby_7.5.1_r8785.bin.sha (404 Not Found), will try again in 10 minutes. Working on getting someone to fix this a.s.a.p... the firmware itself has been qualified for beta release, this is just an administrative task for the checksum on the server. Sorry for the delay.
IT WORKS! Thanks a lot to the SB Community und Developers, Chris
It works fine for me too but only the first time. If i press snooze and my server is going down again after 5 min. my system needs again a WOL before the radio wakes up again.
Created attachment 6861 [details] patch to send wol 5 minutes before snoozed alarm refires Wow, I'm really surprised people have sleep set so aggressively on their server. Nevertheless, here is a patch to deal with that case. note that we're getting into some shaky ground here in that the sleep time is configurable on the server-side, so having WOL happen in time for the server to wakeup in time to be ready for the alarm is going to be somewhat dependent for what that's set to. this patch will send WOL 5 minutes before the snoozed alarm is going to refire, or immediately if the snooze time is less than 5 minutes. I've tested this against the default sleep time of 9 minutes and it works correctly.
Actually, patch is not quite right yet. Will put on the finishing touches next week.
Created attachment 6862 [details] updated patch for sending wol after snooze and before alarm refire this looks better...will test it further next week.
@ben you're right 5 minute shutdown might be a bit too aggressive. But i thing sending an additional WOL paket isn't bad. Really cool would be a config option for the time the WOL paket should be send in advance.
(In reply to comment #47) > (...) Really cool would be a config option > for the time the WOL paket should be send in advance. I totally agree! 5 minutes is a wink too short for my QNAP to finish booting on time.
so this needs to be a config option. My server needs only about 5-10s to recover from standby.
You will need to open a separate bug about the config option for WOL, and I can't make any promises about a date for fulfilling that request. It will definitely not happen for 7.5.1 (while the last patch above probably will) if you want to hack this yourself, enable ssh (settings->advanced->remote login), ssh as user root to the radio (password: 1234), and change this line to whatever you want your WOL lead time to be: local wolLeadTime = 1000 * 60 * 5 -- 5 minutes sorry, that's the best I can offer on that front right now.
for me five minutes are OK. I just wanted to point out that that not everybody needs 10 minutes or more like the people with there embedded NAS.
[additional info] if you want to hack this yourself, enable ssh (settings->advanced->remote login), ssh as user root to the radio (password: 1234), and change this line to whatever you want your WOL lead time to be: local wolLeadTime = 1000 * 60 * 5 -- 5 minutes * the file you want to edit with vi is: /usr/share/jive/share/applets/AlarmSnooze/AlarmSnoozeApplet.lua
(In reply to comment #52) Hi Ben, that's exacly how I solved the problem for the moment and it works. The thing is, that I have to do this hack every time when I install a new Nightly Build with a new Radio FW. And I install every Nightly due to the Radio alarm issues and hope to have them fixed after an update. Christian
Fair enough, but my statement still stands that a config option for WOL lead time will not be added for 7.5.1.
== Auto-comment from SVN commit #8803 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=8803 == Bug: 15663 Description: also send WOL 5 minutes before snoozed alarm is set to refire
Chris: Can you verify that this issue is now fixed? Please use the latest release build (or nightly) when verifying.