Bugzilla – Bug 10163
Radio stream play after Alarm Timeout
Last modified: 2009-03-10 01:27:49 UTC
After an alarm timeout, if play is pressed, the Squeezebox starts to play what is cached from a recent alarm playlist of a radio stream. If play is pressed immediately after a time out, (while there's sufficient stream in cache) everything continues to play as expected. If play is pressed later, the cached stream is played, and then interrupted, and re-streamed again, potentially forcing the listener to miss both interrupted programs and to hear the the beginning radio stream advertisement again. Would it be possible not to play the cached stream, or optimally play the cached stream only if the radio program is not going to be interrupted?
Andy: your thoughts on this?
I don't think this is an alarm bug per se. When the alarm times out, it simply executes a pause. cc-ing Alan for thoughts
This is related to the perennial argument (ongoing discussion) about the distinction between pause and stop, and a related but different discussion about what to do when executing pause on a remote (possibly live) stream (see bug 7320). The trouble is that sometimes pause on a remote stream makes sense, and how long it makes sense for depends upon whether it is a live stream or something like a podcast (and we don't always know which). A short pause (up to a minute or so) on a live stream can make sense but maybe much longer is ok for a podcast (although there is the danger that the stream source will close the connection). The pause/stop issue is related because a user may want to stop the stream but either cannot (because the UI in question, e.g. the WebUI does not have a stop button), or does not know how to (because the press-and-hold-Pause semantics of the SBC or IR interfaces are not obvious to them). The question is how long to allow pause for on a remote stream. One option would be only until the player's stream buffer fills - about 200s at 128kb/s, although many radio streams are half that rate, or less, giving correspondingly more buffered time. The problem with this idea is that it may screw up the podcast-type case.
*** This bug has been marked as a duplicate of bug 7320 ***