Bugzilla – Bug 15901
Backup alarm may sound and cannot be cancelled
Last modified: 2011-01-14 09:51:27 UTC
Touch firmware 7.5.0 r8644 A fab4 was found to be sounding its backup alarm. Earlier in the day a scheduled alarm had sounded as expected. Audio was stopped by some means - probably Pause. Later, the server which the player had been using was stopped and a different server on the same IP address and with the same name started. The server was restarted several times. At some unknown point it the backup alarm started sounding although there had been no alarm scheduled between the morning alarm and the time that it was first observed to be sounding. There was no alarm configured in the (new) server for the player. The backup alarm could not be stopped without a reboot. Using Power OFF, Pause or Stop simply resulting in it starting up few seconds later, even if a track from the server was selected and played.
Created attachment 6652 [details] Some relevant logging
I've not seen exactly this problem, but I've seen the problem where the backup alarm is triggered it's not possible to disable it without rebooting. In my case I used the custom alarm window patch when the backup alarm was triggered. The custom alarm window patch I'm talking about can be found here: http://erlandapplets.googlecode.com/svn/PatchInstaller/trunk/patches/CustomAlarmWindow/CustomAlarmWindow-1.0.patch I think the problem is that if the AlarmSnoozeApplet thinks it's playing an alarm it will continue to force it to be played until the _alarmOff method in the AlarmSnoozeApplet is triggered. It feels like this should be triggered automatically in some cases, for example if you push "Stop" button or when you switch to the off screen saver by hitting "Power" button. Triggering the _alarmOff method will turn off the decodeStatePoller timer inside AlarmSnoozeApplet. However, please note that this still doesn't explain why the backup alarm was triggered in your setup, it just explains why it couldn't be turned off after it had been triggered.
Created attachment 6663 [details] Patch to turn off alarm when (soft) power is turned off the problem with doing this with pause/stop as well is that I can't use the same model in notify_playerModeChange. Mode changes to pause and stop are notifications that will come in e.g. for an alarm snooze, where you actually would _not_ want the alarm cancelled. My recommendation is that this patch be tested and applied post-7.5.0. From what I've heard about when this happens, it happens in non-standard circumstances (multiple servers, switching between them, etc.). If this bug happens in a more common use case, I could be swayed that it's more important. Without that proof, this is 7.5.x.
Ben, regarding killing the backup alarm on stop and pause, maybe you could hook into LocalPlauer.lua.stop/pause(). I guess they should result in calling AlarmSnoozeApplet:_alarmOff(false).
You don't think there's a problem with a core class calling an applet method? That seems like a really problematic approach to me...
Targeting for 7.5.1 at Ben's suggestion that all patch_waiting bugs be fixed
== 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
The patch has been applied, which gives an effective means of dismissing an erroneous alarm (via the power button). The remaining two problems, backup alarm might sound when it shouldn't, and stop/pause does not dismiss the erroneous alarm, have been deemed rare and not needed for 7.5.1, respectively. Retarget remaining issue for 7.5.x FWIW, I'd like to see evidence that the erroneous fallback happens with some degree of frequency before spending a lot of time on addressing that. From what I've read, this should be a fairly rare occurrence with a particular environment (e.g., multiple servers)