Bugzilla – Bug 13602
Alarm snooze options
Last modified: 2011-11-06 23:23:08 UTC
There was some discussion about making big knob = snooze when an alarm occurs. I like it how it currently is - that the knob doesn't cause a snooze. A discussion happened; some good ideas were aired. Some people want snooze, other people want alarms for other reasons (eg. just turning on music at a preset time, not necessarily as a bedroom alarm clock), thus an option on an alarm to define this behaviour would be best. It was suggested that if Alarm Timeout = 0 (or blank), then when the alarm fires, it should play the alarm music, and immediately come out of alarm mode. i.e. show Now Playing screen, and have no snooze behavior. Music would continue until stopped. A positive value for alarm timeout would mean that during that time, the player would be in alarm mode, so there could be a different alarm screensaver, and knob could be used for snooze. The Alarm Timeout should be a setting available per alarm. Someone may like a morning wakeup alarm with snooze/timeout, and other alarms without snooze/timeout. A tooltip message should be added to explain the significance of 0 (or blank?) representing no snooze in addition to no timeout.
I can see this working, but I don't see it making it into 7.4. targeting for 8.0
I'm not sure if the following request fits here, but I'd like to be able to continue playing music that started via alarm, but of course ack. the alarm. Currently, there's a choice to either Snooze, or Stop the alarm (which stops playback). How about a "Ok... play on!" option, essentially?
(In reply to comment #2) > I'm not sure if the following request fits here, but I'd like to be able to > continue playing music that started via alarm, but of course ack. the alarm. > Currently, there's a choice to either Snooze, or Stop the alarm (which stops > playback). How about a "Ok... play on!" option, essentially? I think this solution is actually much more workable than the one in comment 1, and accomplishes the same thing without having to noddle around in settings. A ton of clock radios actually work this way - when the alarm goes off, the radio is turned on, and many (most) people just leave it on while they get ready for work. I like the idea of having a third option - "continue playback" - that closes the context menu and takes the user to the Now Playing screen. Tom, making this a P2 for 7.4, but it seems pretty low-risk, no?
I don't think having a context menu to choose to stop alarm mode and continue playing is addressing the issues raised. There are people who don't want to have to acknowledge the alarm, don't want controls to be overridden to act as a snooze function. We just want to set a time when music will come on and continue to play, displaying the NP screen. Setting Alarm Timeout=0 does the equivalent of acknowledging the alarm immediately, so the user doesn't have to do it. I don't want to see a context menu when an alarm fires. I want to see the NP screen which I have configured to display the current time. As you say, a lot of people wake up and just leave the music playing. When I come back to the player a couple of hours later and try to use the player, I don't want to accidentally snooze.
Tom doesn't have clear direction on this. Assigning this back to me.
I agree with the original comment. There should be NO menu shown when the alarm fires. Most alarm clocks just have the alarm go off. You either keep it playing by doing nothing, or you turn it off entirely. When the alarm goes off, I suggest that you should see the time for perhaps a configurable amount of seconds (say 5 seconds), then it automatically should go to the now playing screen. Having to deal with a menu and a knob turning when waking up is not ideal. Most alarm clocks have one button to deal with when the alarm goes off -- that button simply turns it off. If you want snooze -- that's a separate button.
== Auto-comment from SVN commit #29673 to the slim repo by bklaas == == https://svn.slimdevices.com/slim?view=revision&revision=29673 == Bug: 14578 Bug: 13602 Description: allow stop:1 as a param to the jivealarm cli command
== Auto-comment from SVN commit #8254 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8254 == Bug: 14578 Bug: 13602 Fixed Bug: 14238 Description: do not pause playback when turning alarm off. this fixes the bug reported in 14238, where the iconbar was not showing the correct state for the next alarm I will probably be adding a third option to the alarm window this week that will stop the alarm and stop the audio. Also considering timing out the alarm notification window and hiding after X time (audio would continue running).
== Auto-comment from SVN commit #8255 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8255 == Fixed Bug: 14578 Bug: 13602 Description: when alarm fires and player is connected push to NP screen before pushing the alarm notification window to screen remove alarm window from screen after 59 seconds
Matt doesn't work for us anymore. This bug seems like a decent place to discuss this issue though.
The display of the popup modal dialog is specific to Radio (and Touch?); there should be a separate setting to define how the alarm interface works dependent on player type. This could be handled generically, by having an Alarm Display ("Screensaver") mode, so the user could pick an appropriate display mode (per-player setting, like other screensaver mode selections). eg. either "Popup Dialog" (perhaps the default), various clock displays, Now Playing screen, etc. If Alarm Timeout = 0, the player won't be in alarm mode, and therefore the "When Playing" screensaver would always be displayed.
I agree with Phil's suggestion. In addition, leave the current button mapping as is - that is a "back" button acknowledges alarm, but allows to keep playing (for Alarm Timeout > 0); volume knob push for "snooze" and power button for "alarm off"... this combined with ability to choose different "when alarm" screensaver (if desired) would solve many users complaints - most common being that in alarm mode the clock is too small.
I agree with Phil at comment 11. This change would restore functionality which had been present in the alarm for all SB devices since kdf first wrote his plugin years ago. This has been lost on the Radio with recent changes, and greatly reduces its usefulness as a music scheduler. Also, the recent change to force the alarm sound to the internal speaker should be made an option, again for the convenience of those who use the Radio with external speakers via the headphone jack. Bill
Unassigned bugs cannot have a priority.