Bugzilla – Bug 8236
Alarm should have a configurable time limit
Last modified: 2009-09-08 09:28:18 UTC
Since Boom will be used by many as a clock radio - I believe radio streams for Alarm has to be supported properly. This means 1. Easy to set up streams as the Alarm source. My preference would be to have preset buttons, Favorites and Playlist in the list of alarm sound sources. Using Favorites is already used on Squeezenetwork. At present only playlist are supported to a radio stream has to be put into a playlist. 2. When Alarm goes off with Radio stream - if the stream does not start playing within say 15 secs - the alarm has to fall back to known definite audio source. This can be easily implemented in DateTime plugin, by comparing the elapsed time of the playing stream against the time since alarm went off. If stream is not playing -the a predefined alarm playlist should be started. There is an issue about "snooze" as a 9 minutes snooze pausing a stream will probably result in a stream disconnect and not pause and so when snooze ends the stream will have to be restarted. Also there have been some user comments that for some stream elapsed time moves but there is no audio - I think is mainly an installation issue. Although this fallback behaviour is proposed mainly for stream - it is applicable also for playlist where audio files no longer exist or have become inaccessible (e.g. file server crash). This could mean recommending to the user that fallback audio sources should be an audio file on the same PC as SC. 3. There needs to be a time limit to the alarm. For countries/ISP with bandwidth restrictions users do not want radio streams playing all day. This limit can be implemented by effectively having a "sleep" activated after an alarm goes off. 4. There should be a separate setting for "Alarm" brightness in addition to Power on, Power off and Idle. At present alarm uses "idle" brightness (except for the initial short burst of "power on" brightness when audio starts). "Idle" brightness will be dim and when alarm goes off it may not be possible to see the display without hitting a key which either cancels the alarm or starts a snooze. With a separate "Alarm" brightness the user can select the display brightness as they fit and not a compromise with idle which is probably used when falling asleep and also there could be no initial burst of Power on brightness which could be max. Some of these enhancements have been mentioned in other bug reports but the emphasis here is on the use of streams and special restrictions associated with streams (i.e. unreliability as a alarm audio source and usage costs).
I've split point 4 out into bug 8240 as this is a general point, relevant to all types of alarm.
Max do you have an interest in looking at some of the other items in this bug as well? :)
1) is bug 8566 2) Is covered by bug 8577 and bug 8499. 4) is bug 8240 That mostly leaves 3. For clarity, it might be worth refiling that as a separate bug - this one is just too confusing! Time limits are maybe interesting, but it would have to be a pref and would depend upon knowing that a radio station is being played. I think this needs more thought.
I think time limit is important. I always assumed it would be a pref just like snooze time should be a pref and not fixed at 9 minutes.. Besides the bandwidth issue , most clock radio turn off the alarm after a period of time otherwise the alarm could be ringing all day which could annoy other house mates who do not know how to turn off Boom alarm. I can't see why it is necessary to know the station to implement a time limit. I haven't looked at the new code but in the old code I expected the "flashing bell" code could be used track how long an alarm has been ringing and if it exceeded the pref time limit, issue a command to stop playing. I'll see if I can put together a patch to demonstrate.
You're quite correct - I was forgetting that time limit would apply to all alarms and not just radio stations. It should probably be a global server pref. The default should probably be unlimited? Thoughts anyone? Incidentally, snooze length is a pref, it's just not exposed yet.
I had thought it would be per player pref. Since alarm settings are per player - I reckoned it would be logical to have the alarm time limit with other alarm settings. The only other reason would be a house with multiple booms - each user would have different preferences. I also thought the default would be a limit of about 1 hour as I think having a limit is normal for a clock radio. However as long as there is a limit - I don't really mind what the default value is.
Agreed. I may have typed global server, but I'm sure I meant per-player. ;-) Any thoughts, Dean?
This bug is actually now a dup of bug 4775, but that bug is not Boom only.
*** This bug has been marked as a duplicate of bug 4775 ***