Bugzilla – Bug 15998
Squeezebox Alarm goes to Backup alarm too quickly.
Last modified: 2011-01-17 16:16:06 UTC
My squeezebox has very good connectivity. Most of the time (perhaps 8/10 times), however, the alarm goes to the backup sound rather than the preset station. This happens when the radio is doing nothing and also when the radio is already active (i.e. playing a different stream). This bug was reported last year (as 15040). It was incorrectly labelled as a duplicate of 11611 and marked as resolved (I am filing this as a new bug because I seem unable to change the status back to reopened). 11611 is a completely different issue, however, that involves the backalarm stuttering or not going off. This bug involves the radio going too quickly to the backup alarm rather than the intended stream. The solution to this bug is probably pretty easy. I suspect all that needs to happen is that the check for connectivity that precedes the backup alarm needs to be lengthened. From the logs posted under 15040 it looks like the backup alarm fires if the stream is not up and running within 20 second. Perhaps if it were set to 50 seconds or 59, the problem would be for the most part solved. The only thing I don't quite understand is why 20 seconds isn't enough: when I push a preset button, most of my stations seem to load within 5 or 10 seconds. The only thing I can think is that the connectively test for the backup alarm is starting before the stream starts loading, meaning that the streams are actually getting less than 20 seconds to load before the alarm kicks in. This is a trivial thing to try fixing and I'd do it myself except the lua language is new to me and I can't quite figure out where the parameter is stored. A feature request related to this in the future might be to allow the user the option of adjusting the time the radio takes before the backup alarm kicks in as a way of fine tuning connectivity problems.
I have been having a consistent problem with my Squeezebox radio alarm. It only comes on with the radio station I have selected intermittently. For example, this week the radio station WTOP in Wash. DC came on Tues and Wed, but the backup musical beat came on Thurs. Fri. and Sat. However,this morning, Sun. 4/25/10, the radio station came on. This week the radio was set on wireless, but when I experimented with a wired connection in the past, the same thing happened. When the backup comes on, I immediately hit the preset for WTOP and it comes on right away. So far Logitech has not come up with a solution. This has been a very annoying problem for us. My software is up to date.
I saw this was reassigned to the server. I suppose if you are sure. But it is happening on a squeeze box and in my case, I'm not using the server functions (explicitly, anyway, AFAIK). I will say that my analysis of the problem is starting to change. While I think lengthening the time before the backup will help, I don't think any more that the problem is simply that the streams are not being given enough time to load: I think the timing loop is starting considerably before the stream is even launched. Using a preset button, I can get a stream to launch in about 3 seconds. This should be well within the time allotted by the alarm. So I now think it may be starting the testing period for the fallback alarm 15 seconds or so before it actually tries to launch the stream. IMO, the whole alarm sequence needs to be rethought: it is incredibly unreliable and full of poor behaviour: it times out too fast, if a stream is playing, it sometimes "alarms" to silence, the alarms sometimes cut out after 10 minutes or so, and when the alarm starts, it puts up a decision screen that contains only "snooze" or "turn off", and doesn't allow you to select "keep playing." While you can let it keep playing by just not doing anything at the screen, not doing anything means that you don't get the screen with the clock back... meaning that you can't easily see how late it is. I'm a fan of linux devices, and I'd really like a good internet radio alarm, but I have to say I'm about to give up on the SB. My wife who is not interested in things unless they work, wants to chuck it or move it somewhere that is less critical.
I just realized, that I duplicated your bugreport. (see bug #16190). As the other one has more votes already (and isn't 'unconfirmed' anymore because of that) I'd suggest you moving over to #16190 ? https://bugs-archive.lyrion.org/show_bug.cgi?id=16190
I can pretty much conclusively say that this is a server problem and not a radio problem. I set the alarm to go 3 minutes before the hour and it now never goes to backup (except very occasionally due to another, unrelated bug).
Ben, Chris, I think we should include the increase of the interval for the go-to-backup alarm timer in any update that we may push out for other problems. I am sure that this could hit many people, especially at popular on-the-hour times for alarms, because the current timer could easily be less that the time it can take to start an internet radio stream or a service such as Pandora.
Dan, can you confirm what product you are using? Your original report specific a Squeezebox 2/3 but from your subsequent comments I suspect that you could be referring to a Squeezebox Radio or a Squeezebox Boom. My previous comment, above, was on the assumption that this report really refers to a Squeezebox Radio.
(In reply to comment #6) > Dan, can you confirm what product you are using? Your original report specific > a Squeezebox 2/3 but from your subsequent comments I suspect that you could be > referring to a Squeezebox Radio or a Squeezebox Boom. > > My previous comment, above, was on the assumption that this report really > refers to a Squeezebox Radio. Hi Alan, You're right: it is the radio that I have, I just double checked. A related/unrelated problem that has crept in since the last update is that I now have it occasionally start a radio feed then go to backup alarm after a few seconds (for alarms beginning just off the hour). I think this is actually tied to a problem about Snooze and Pause cause feeds to pause rather than stop. Unless you really hold Pause in order to stop a feed, you never really seem to clear the feed (including, BTW visual information such as the station logo) and from then on any feed you start stops after a short interval (ranging from a few seconds to a minute or two)--the new feed does not display visual information: it runs under the screen for the feed that was paused instead of stopped (there's also a pause icon in the lower left rather than a stop or play when this happens) This is associated with the alarm, because if you have sleep on the night before, your alarm the next morning seems to be affected by the bug. The only solution that seems to fix things is a reboot. If you get to it before a new feed starts, you can sometimes prevent the problem by holding pause and stopping the paused feed.
Combining fallback/backup alarm bugs into bug 16663. *** This bug has been marked as a duplicate of bug 16663 ***