Bugzilla – Bug 11611
Backup alarm sometimes doesn't play when set to Internet Radio Stream
Last modified: 2011-01-24 09:10:47 UTC
Boom alarm doesn't always work when either the wireless signal strength is weak or if the internet connection speeds are slow. Customer reported this issue. When his Boom is in the area he wants it to be, he gets roughly a signal strength between 50-60%. Setup: Boom is wireless Has an internet radio stream for the alarm sound Connected to Squeezenetwork Issue: Alarm may go off, but he will only get audio for about 15 seconds, then the Boom will exhibit a buffering type issue and any of the following may happen 1. The Boom will be on the now playing screen with the stream paused 2. The Boom will be on the now playing screen with the stream stopped 3. The alarm will activate, but customer never hears any audio What we've tried: 1. Connected to SqueezeCenter: Alarm works fine in the same area 2. Moved to a better signal location: Alarm works fine 3. Just played the streams used for the alarm in the poor signal area: streams play fine 4. Tried different internet radio streams in the poor signal area: intermittent issues Also, I was unsure if this was a duplicate of: https://bugs-archive.lyrion.org/show_bug.cgi?id=9534 so I just filed this as a new bug.
Customer also states that out of 12 tests, his backup alarm only activated 3 timee. Twice it failed after 15-20 seconds.
Working with the customer we have determined that the alarm will fail to play Internet Streams properly, falling over to the back up alarm. When selecting any remote stream (RadioIO/RadioTime/other URL's) as the alarm sound, the alarm will fail to start the stream. The back up alarm will properly trigger instead. When selecting any of the Sounds & Effects as the alarm sound, the proper alarm sound will trigger When selecting a local file as the alarm sound, the proper alarm sound will trigger
Created attachment 5969 [details] Server Log See attached log. 4 alarms were set, only 3 triggered properly 8:00 = Local Internet Radio (Radio Time URL) = Failed to start, back up alarm triggered 8:10 = Radio Paradise = Triggered properly 8:15 = Pandora = Triggered properly 8:20 = Live365 = Triggered properly
The first one (08:00) failed because it could not connect to the radio stream: [09-10-01 08:00:05.0703] Slim::Utils::Scanner::Remote::__ANON__ (225) Error: Can't connect to remote server to retrieve playlist for, http://opml.radiotime.com/Tune.ashx?id=s34804&formats=aac,mp3,wma,wmpro,wmvoice,wmvideo,ogg&username=jamesrichardson&partnerId=16: Connect timed out: Bad file descriptor. The radio connection timeout is pretty aggressive.
Ben to add some log messages around the failure to play, then assign back to QA for further investigation. Depending on QA's findings we may wish to reconsider the target, priority, etc.
This happened to my Boom this morning. The device powered on at the correct time but did not play. Very annoying, as since the upgrade to ver 50 - things have been pretty reliable. I tried pressing a number of my preset buttons to get some noise - but only some of them would play... which might've been a problem with Squeeze Network? "Groove Salad" (one of the default presents?) worked fine but several (but not all) local stations which have been sourced by SqueezeNetwork (Internet Radio > Local) did not play. I have not rebooted the device, or my router as I want to see if it will sort itself out during the day. BUT - this does highlight the issue here: If the selected stream is not available or working for any reason - the Boom simply MUST make some noise. Otherwise it is wrong to market the thing as an alarm clock!!! If you need more details of the stations etc that didn't work please let me know. James Based in New Zealand.
James: can you verify if your ISP changes IP address on you? see bug 14870
*** Bug 15040 has been marked as a duplicate of this bug. ***
*** Bug 15083 has been marked as a duplicate of this bug. ***
i almost NEVER get the remote radio stream to play: in the last two months it only ever worked TWICE, the rest of the time i get the backup alarm, once (today) i got no alarm at all! pressing on the preset button for the radio stream almost always gets the stream playing right away. seems to me there is something rather fishy with the network settings...
Just a clarification, this bug is against the Boom not SB Radio. Let's discuss the bug and who's responsible for the fix at the next bug meeting.
i filed against SB Radio (bug #15050), which got classified as duplicate of this. so, is it a duplicate or not? it would be really nice to get this working as advertized...
(In reply to comment #12) > i filed against SB Radio (bug #15050), which got classified as duplicate of > this. so, is it a duplicate or not? > > it would be really nice to get this working as advertized... sorry, that should read bug #15040
I can confirm comment 10 on the squeezebox radio: we have good connectivity, but the alarm almost always goes to the backup sound rather than the selected stream from "favorites" /even if a stream is actually playing at the same time/ (i.e., it will shut down a working stream and replace it with the backup sound when the alarm fires). This happens probably about 80% of the time. This morning alarm 1 fired backup sound; alarm 2 (an hour later) the desired stream. Yesterday, both fired the stream. All week previously, the backup sound has gone off even if a radio stream was already playing (demonstrating connectivity). It looks to me like the problem may be that the alarm is jumping to backup too quickly--even though we get streams loading very quickly, they can take 5 secs or so. I wonder if the timeout for the alarm (i.e. the time it takes to go to a station) is maybe not triggering at just faster than the minimum amount of time it usually taking for a stream to load, meaning that most times it goes to the backup, but very occasionally a stream loads faster than normal and so launches. Is there a setting I might be able to adjust by SSHing in? P.S. would it be possible in the meantime to perhaps be able to select a backup sound? The one we get is not to my taste, anyway.
(In reply to comment #14) I should add having looked at the duplicate bug, that while our IP number is theoretically variable, it hasn't changed in months, and that the squeezebox itself has an assigned local IP number.
Dirk, Dan, This sounds like a different bug, along the lines of "Backup alarm plays more often than reasonable". It may indeed be that the backup timeout is too short - I would expect it to be around 45s. Perhaps you would like to open a new bug report for this problem. I would suggest including the text from comment 14. Ben, was the main topic of this bug report not fixed with 7.4.2? Alan.
Glad to see some activity! It's been very close to a year that I've owned a boom now and I still do not have a dependable alarm! Neil
Please also note that the mechanism by which a backup alarm is triggered is quite different for Squeezebox Radio and for Squeezebox Boom. Please report issues relating to a backup alarm under a bug report associated with the specific product.
(In reply to comment #16) > Dirk, Dan, > > This sounds like a different bug, along the lines of "Backup alarm plays more > often than reasonable". It may indeed be that the backup timeout is too short - > I would expect it to be around 45s. Perhaps you would like to open a new bug > report for this problem. I would suggest including the text from comment 14. > > Ben, was the main topic of this bug report not fixed with 7.4.2? > > Alan. I can't get the status of 15040 changed to reopened. I've tried filing a new bug to see if this prompts any movement. As far as I can tell this is a serious problem (my wife now wants rid of the radio, since its alarm is so unreliable and the backup sound so annoying) with a trivial solution. Does anybody on this bug no enough of the language to help me find where the time-out test for the backup sound is set? I imagine it can be solved by just increasing the value of the loop.
I know this bug is a duplicate of another. Hopefully somebody remembers during bug meeting.