Bugzilla – Bug 16190
Fallback alarm sounds too often
Last modified: 2011-01-17 15:42:05 UTC
I think its time to open a new bug-report for alarms. In 7.4.2 we made the alarm very robust - very rarely users are now complaining that the alarm didn't fire at all (which is a step in the right direction). On the opposite users are hearing fallback alarms much too often (it seems most of the time when connected to MySB.com - which I guess is the bigger audience for SB-Radio ?). (As a sidenote - I'am using a local SB-Server so don't face these problems) The interesting question of course is, if problems related to network can be solved. Some thoughts: - is there any Logitech employee using a Radio at home together with MySB.com ? Its very difficult for users to provide logs when the fallback alarm sounded - I think someone from logitech would be better suited to the task. And to be honest - I think it would also change the priority of this bug very fast - if the problem is just because of small network drops ... can't we change the alarm code to just sound the fallback-alarm when the audio-buffer is empty ? Of course we still had to put the Radio into fallback-mode once the server disconnected to prevent the alarm failures we had before. But maybe the alarm handling code should be splitted into a) 'MySB.com-Down - but original stream still valid => switch to "DoNotTrustTheServerAnymodeMode" (but keep playing original stream)" vs. b) 'MySB.com-Down - StreamBuffer empty => fallback alarm tune'. - fix it by starting to write local alarm-handling code. This code also just had to look for empty Stream-Buffers to sound the fallback alarm. But all the code regarding SB-Server disconnection could be omited. I'll be going on to link forum articles here ... if possible even logs. I'm tired of complaints you should be responsible for ...
http://forums.slimdevices.com/showthread.php?p=544152#post544152 User moved alarm from 7:00 to 7:03 and now he didn't have a fallback alarm (at least for two days). Thus sounds MySB.com related.
Absolutely agree. I have my alarm set for 8:00 AM M-F, and the radio station I selected has never once been the first thing I hear - it's ALWAYS that busy little disco number. However, I think user dwstuck in the forum may be on to something. Every time I've tried to test the alarm by setting it to some random time of day (say I sit down with it at 5:20 in the afternoon and program a test alarm for 5:22), it works correctly. Thus I've never been able to replicate my 8:00 AM experience at a time when I'm more awake :) I'm going to try setting it for 8:03 tomorrow and see what happens.
I have a 45 minute timeout for my alarm and I'm using a local server. It usually starts by playing the normal music but some time during the 45 minutes it always switch to playing the fallback alarm. I've looked in the log and I'm pretty sure the cause is a temporary very brief network connection with the server. I never had any problems in 7.4.1.
*** This bug has been confirmed by popular vote. ***
I have had the same problem erland mentioned. The alarm stream started to play correctly, but about 20min into the alarm the backup alarm.mp3 suddenly took over. I am using a local SBS that is up 24/7.
(In reply to comment #2) > Absolutely agree. I have my alarm set for 8:00 AM M-F, and the radio station I > selected has never once been the first thing I hear - it's ALWAYS that busy > little disco number. > > However, I think user dwstuck in the forum may be on to something. Every time > I've tried to test the alarm by setting it to some random time of day (say I > sit down with it at 5:20 in the afternoon and program a test alarm for 5:22), > it works correctly. Thus I've never been able to replicate my 8:00 AM > experience at a time when I'm more awake :) > > I'm going to try setting it for 8:03 tomorrow and see what happens. I've experienced this: the first alarm is the one that doesn't go off properly, usually by going straight to the backup alarm, but sometimes by going to the correct station and then after a few minutes going to the backup or simply going to silence. Subsequent alarms tend to go off properly, although sometimes if a stream is playing the shut it down to silence. I'm thinking there must be some kind of hibernation issue causing trouble with the first one. It is also the case if you look at the logs, or even test it with a stop watch, that the testing loop is clearly longer than most stations take to load, even when cold starting. So on my SB, most stations take about 3-5 second to start; as far as I can tell, the alarm fallback fires after about 20 seconds; meaning some time must be being wasted before it attempts to initiate the stream.
I think the suggestion that it might be a server problem is probably correct. We changed our alarm to 6:58 MDT from 7:00 MDT, and it suddenly works 90% of the time, as opposed to 10% of the time. This agrees with my experiments with load times, that suggest that although most of my stations load in 3 secs or so, the 20 secs delay before the backup alarm is fired is not sufficient. So everybody, set you alarms to something other than the hour... or :58 so you don't screw with mine ;) (In reply to comment #6) > (In reply to comment #2) > > Absolutely agree. I have my alarm set for 8:00 AM M-F, and the radio station I > > selected has never once been the first thing I hear - it's ALWAYS that busy > > little disco number. > > > > However, I think user dwstuck in the forum may be on to something. Every time > > I've tried to test the alarm by setting it to some random time of day (say I > > sit down with it at 5:20 in the afternoon and program a test alarm for 5:22), > > it works correctly. Thus I've never been able to replicate my 8:00 AM > > experience at a time when I'm more awake :) > > > > I'm going to try setting it for 8:03 tomorrow and see what happens. > > I've experienced this: the first alarm is the one that doesn't go off properly, > usually by going straight to the backup alarm, but sometimes by going to the > correct station and then after a few minutes going to the backup or simply > going to silence. > > Subsequent alarms tend to go off properly, although sometimes if a stream is > playing the shut it down to silence. > > I'm thinking there must be some kind of hibernation issue causing trouble with > the first one. It is also the case if you look at the logs, or even test it > with a stop watch, that the testing loop is clearly longer than most stations > take to load, even when cold starting. So on my SB, most stations take about > 3-5 second to start; as far as I can tell, the alarm fallback fires after about > 20 seconds; meaning some time must be being wasted before it attempts to > initiate the stream. (In reply to comment #6) > (In reply to comment #2) > > Absolutely agree. I have my alarm set for 8:00 AM M-F, and the radio station I > > selected has never once been the first thing I hear - it's ALWAYS that busy > > little disco number. > > > > However, I think user dwstuck in the forum may be on to something. Every time > > I've tried to test the alarm by setting it to some random time of day (say I > > sit down with it at 5:20 in the afternoon and program a test alarm for 5:22), > > it works correctly. Thus I've never been able to replicate my 8:00 AM > > experience at a time when I'm more awake :) > > > > I'm going to try setting it for 8:03 tomorrow and see what happens. > > I've experienced this: the first alarm is the one that doesn't go off properly, > usually by going straight to the backup alarm, but sometimes by going to the > correct station and then after a few minutes going to the backup or simply > going to silence. > > Subsequent alarms tend to go off properly, although sometimes if a stream is > playing the shut it down to silence. > > I'm thinking there must be some kind of hibernation issue causing trouble with > the first one. It is also the case if you look at the logs, or even test it > with a stop watch, that the testing loop is clearly longer than most stations > take to load, even when cold starting. So on my SB, most stations take about > 3-5 second to start; as far as I can tell, the alarm fallback fires after about > 20 seconds; meaning some time must be being wasted before it attempts to > initiate the stream.
QA to repro. Also, follow up with IT regarding CPU spikes on the hour at various sites from overwhelming numbers of players requesting streams.
Alan suggests a network query to see if affected users have some commonalities in their alarm settings.
Just a suggestion: The fallback alarm will always sound when the 'endless' cometd-connection is disconnected. This can happen because of soo many reasons: - proxies and routers that don't like endless connections - very small spikes on your own servers - very short WLAN disconnection/reconnection (which with any other device users wouldn't even notice). So I don't think searching for reasons why the connection would drop (and trying to avoid them) would lead to a proper solution ?
*** Bug 16156 has been marked as a duplicate of this bug. ***
wrt the fallback alarm: there REALLY needs to be a way to both select a different alarm, and to be able to set the volume, as well as have it fade in.
Combining fallback alarm bugs into single bug 16663. *** This bug has been marked as a duplicate of bug 16663 ***