Bugzilla – Bug 13968
Losing network connection causes alarm to fail, disables snooze
Last modified: 2009-10-30 13:24:48 UTC
My router is admittedly flaky at times, but that flakiness has led to the Squeezebox Boom to perform unexpectedly and unreasonably in regards to the alarm clock. There have been a couple of occasions when the alarm failed to go off, but I wasn't able to document exactly what happened. This morning I completely caught it in the act in the time between my alarm and the alarm of my spouse. - My alarm went off, and I pressed snooze - Unrelated to the Squeezebox or Squeezecenter, my router went down. - The Boom "forgot" that I had pressed snooze: it did not sound my alarm again when it was time. - Later I rebooted the router, and coincidentally it was during the time that my spouse's alarm should have gone off. The alarm did NOT go off, instead the Boom was displaying a "can't connect to squeezecenter" message. So there it is: not for the first time, the Boom's alarm has failed to sound. This time we got lucky; it HAS caused us to miss work. While I understand that I have a router issue and need to work on that, I think that it is unacceptable that the Boom's alarm and snooze functions are anything other than rock solid. Certainly the use of it as an alarm clock was part of the spousal acceptance factor, without which there would have been no purchase. I need the alarm to perform at least as well as a $10 drugstore alarm clock with a 9 volt battery (which is what woke us up one (late) of the times that the Boom's alarm failed in the past)
What router Mike?
(In reply to comment #1) > What router Mike? A D-Link DIR-655 Hardware Version: A3 Firmware Version: 1.21. For a long time it has had to be rebooted every three weeks or so; recently I got a laptop with 802.11n and it seems to require a reboot a little more often.
Ahh Dir 655, we've had a number of issues with this wonderful piece of technology before. Could you try disabling QoS packet shaping and see if that reduces your need to reboot and improves your boom experience? Bug 9208. Do you wonder at all if this could have anything to do with bug 13970?
(In reply to comment #3) > Ahh Dir 655, we've had a number of issues with this wonderful piece of > technology before. Could you try disabling QoS packet shaping and see if that > reduces your need to reboot and improves your boom experience? Bug 9208. Do you > wonder at all if this could have anything to do with bug 13970? My real issue is that the Boom alarm isn't stable through network instability: watching it say "connecting to squeezecenter" when it should have been waking us up was beyond disconcerting, especially when, after the connection was re-established, it still didn't sound the alarm or realize that it had been in snooze mode with a current alarm. With that said, and while I hope you folks will still make the alarm better regardless of my router, I will try disabling both QoS and WISH, to see if the router requires less rebooting if nothing else. Note that I only recently enabled WISH, I've had alarm problems without WISH. But I've had QoS enabled the whole time...indeed, QoS and gigabit wired ethernet were the two reasons I bought this router :( Home router issues shouldn't be affecting bug 13970, as I'm having that problem even remotely.
Any news Mike?
(In reply to comment #5) > Any news Mike? No news. The problem doesn't happen that often, so if we have to wait for another network failure we might have to wait a while. Do you want me to *force* a network failure?
(In reply to comment #6) > (In reply to comment #5) > > Any news Mike? > > No news. The problem doesn't happen that often, so if we have to wait for > another network failure we might have to wait a while. Do you want me to > *force* a network failure? I note in Felix's reply to bug 12319 (https://bugs-archive.lyrion.org/show_bug.cgi?id=12319#c13) that there are two levels of backup alarm: one is used when there still is a network connection and the desired playlist or radio station fails to play and the second is when the network connection is lost when the alarm is due. He indicates that Bug 12319 is about the second type of alarm. I think my experience also falls into that second category, but I want to note again that the issue in this bug is not that the alarm only sounded for a minute, it is first that the network failure hit during the snooze cycle of the first alarm and then when the network came back up it didn't resume the snooze, and second that on that same morning when the router was rebooting during the time of the second alarm the backup alarm didn't sound (it was connecting to squeezecenter). And while I was able to witness this particular one I have had general alarm unreliability and agree with comment 12 on bug 12319 that I'm hoping the Boom alarm can be 100% rock solid, that specifically the alarm function should take priority over other real-time stuff that the box is doing, and that further if the network state does change during an alarm "session" (i.e. alarm is currently sounding or is in snooze state) that the alarm session will continue even as the networks state changes around it.
(In reply to comment #6) > No news. The problem doesn't happen that often, so if we have to wait for > another network failure we might have to wait a while. Do you want me to > *force* a network failure? Please do force the failure and share reproduction steps if you would be so kind. :-)
I have been testing with 7.4.1 and r50 (for boom). For me the System Backup alarm as well as the Device Backup alarm are working as expected. 1) When connected to a server (SBS/SN), and desired alarm stream cannot be played, backup alarm sound is played 2) When not connected to a server (SBS/SN), and desired alarm stream cannot be played, backup alarm sound is played