Bugzilla – Bug 16295
SB Radio changes state & display on its own.
Last modified: 2010-09-13 11:52:54 UTC
I thought this problem was 7.5.0 related, but it is still present in 7.5.1. My radio changes the state it is in, and what it dispalys. It enters the boot up sequence immedaitely and automatically if a) I have just powered it off with a long hold of the home button, or b) I plug it in i.e. it is impossible to have it plugged in and turned off (no display) Also when I turn it off and leave it, it goes through the following sequence and displays: a) the off screensaver for indeterminate period b) now playing screen for 10 seconds (my screensaver delay) c) stopped screensaver for indeterminate period, minutes to hours d) it then reboots, hard to notice this as it can happen many hours after it has last been used, but on 3 occasions I have happened to notice the Logitech logo displaying, followed by normal boot up sequence n.b. like in the morning before I use it after listening to it when I went to bed. e) then the menu permanently, i.e. it fails to display the clock screensaver that I have set for ALL states with a 10 sec delay All of the above without it being touched.
*** This bug has been confirmed by popular vote. ***
When I said "i.e. it is impossible to have it plugged in and turned off (no display)" it would be more accurate to say "it is impossible to have it plugged in and powered off"
Commenters, are you connected to a local server or to mysqueezebox.com when you are seeing your respective symptoms?
(In reply to comment #3) > Commenters, are you connected to a local server or to mysqueezebox.com when you > are seeing your respective symptoms? In my case it's mysqueezebox.com.
ditto, I only use my radio in the bedroom when my server is switched off, so it is always connected to mysqueezebox.com. Also an update to the above info which were all observed with 7.5.0. and seemed to be a very predictable sequence in all respects other than timing (which could be, as I said, minutes to hours) . Since 7.5.1 I have noticed 2 different behaviours but I cannot be certain of course that these did not also happen under 7.5.0. as I do not spend all day watching my SBR display! a) I have seen it go from dispalying the menu which I thought it did permanently, back to the clock screensaver b) I have (just once) seen it displaying the clock screensaver while it is playing, even though I have "now playing" as my "when playing" screensaver (and a clock for all other states)
OK - I switched to my local server from mysqueezebox.com to see if it makes a difference. I did the following: a) connected to my local server and played a bit of my music b) powered off by holding the home button for 3 secs. The unit auto rebooted as usual so no change there. c) turned it off with a short hold of the home button. It displayed the off screensaver b) 2 hours later it was displaying the stopped screensaver c) 4 hours later it was displaying the menu So, basically no difference, my unit appears to do the same thing regardless of whether it was last connected to my local server or mysqueezebox.com
*** Bug 16234 has been marked as a duplicate of this bug. ***
Anecdotal report by an internal Logitech user that saw: 1. Radio playing Preset 2 switching to Preset 1 by itself. 2. Radio turning on a 11:00 am by itself. No info on version number, but I believe connected to MySB.com only.
I can't reproduce this: both my players (one connected to mysb.com, one to a local SBS) have been playing overnight with no hiccup. The one connected to mysb.com has now been playing Radio Paradise for about 20h. Maybe it's related to the radio stations? What are you listening to?
(In reply to comment #10) > I can't reproduce this: both my players (one connected to mysb.com, one to a > local SBS) have been playing overnight with no hiccup. The one connected to > mysb.com has now been playing Radio Paradise for about 20h. > > Maybe it's related to the radio stations? What are you listening to? For me, it happens when I'm listening to "PR 3 Polskie Radio" or "Radio ESKA Rock" (mostly listening to these two), both polish radio stations - not sure if you want to be listening to this for 24h ;-) The other problem I encounter a lot is that the artwork is not updating when I'm changing the radio (with presets) but this belongs to other bug report...
Created attachment 6892 [details] log when interruption happened Ok, "Radio ESKA Rock" stopped after about 3.5hrs.
The new comments seem to be drifting off the original bug, i.e. with comments about stations stopping playing - yes that is still sometimes a problem but it is not what this bug is about. This bug is to do with what the radio does on its own after it has been turned off. I have received a request from Logitech to return my radio to help analyse this problem. As soon as I receive the replacement I will pack up and despatch my current one. I hope it helps to identify the issue. I will post my experiences with the replacement radio here.
(In reply to comment #13) > The new comments seem to be drifting off the original bug, i.e. with comments > about stations stopping playing - yes that is still sometimes a problem but it > is not what this bug is about. This bug is to do with what the radio does on > its own after it has been turned off. Right. Sorry, I've just quickly read Michael's comment about not being able to reproduce the radio stopping problem so I shared with my experiences. The main subject of the bug - e.g. radio turning itself on after switching it into standby mode - still applies to me. This still happens to me from time to time.
I have now received my replacement radio. I have set it up exactly the same as the first i.e. same location, same router, same firmware, same msb.com account etc. Result after 24hrs - it seems to work as it should and does not display any of the problems posted above, i.e. it stays powered off,and displays the correct screen saver. So it does appear to be a hardware fault with that particular unit rather than a general firmware bug.
I am posting my recent experience with 7.5.1 firmware here in the hope that it helps somehow. Tech support told me it might be a hardware problem. They swapped my radio for a new one. The issues are the same. The following are the details. I also posted this under bug 16170 since I think they are related somehow. First, some foundational comments: The behaviors described here happen whether it is connected to wireless network or to Ethernet cable. Radio is connected to MSB.com. Not connected to SBS. SBS is off (as is the computer which has SBS loaded). There are no other computers on either hard wired or wireless. The computers are off. In my descriptions below, when I say “off” or “turn off” I mean just a short push of the power button, not a full shut down. When I say shut down, I mean a press and hold of the power button. My screensavers are as follows – Off (Digital clock – Black); Stop – Analog Clock; When playing – Now Playing; Screensaver delay is 30 seconds Normally, when I turn the radio off, I do a short press of the power button. I don’t do a shut down unless I am looking to reset the radio. If I do a shut down, it doesn’t normally come back on by itself (but sometimes it does – not often). The following sequence can be duplicated more than 90% of the time. 1. The radio is off (Off screensaver displayed) 2. I turn it on using the power button – It has a “pause” indicator showing in the lower left hand corner 3. It turns off by itself within about 15 seconds 4. It turns on by itself in a minute. Displays the last stream’s art. Shows a “Pause” icon in the lower left hand corner. 5. It goes into the “Stop” screensaver (digital clock) after 30 seconds 6. It remains in this state until I intervene 7. I press the Power button – it goes to a screen showing the last thing that played (with a pause indicator in lower left hand corner) 8. I press the power button again – it turns off 9. It turns on by itself in about a minute with a stop indicator in lower left hand corner 10. It goes to the “Off” screensaver in about 30 seconds 11. It goes off by itself in about 30 seconds 12. It stays off. The following sequence can also be duplicated more than 75% of the time: 1. Turn the radio on with a preset or turn it on with the power button and then hit a preset. Radio streams (stream can be either a radio station, Pandora or Sirius station). 2. Radio turns off within about 15 seconds 3. Radio turns itself back on usually with the “Play” icon in the lower left hand corner 4. I press the pause button; icon changes to “Pause” 5. I press the play button and then stream restarts 6. At this point, it usually continues to play 7. I turn the radio off 8. Unit turns itself on within a minute (with stop icon in lower left hand corner) 9. After 30 seconds it goes to the “Stop” screensaver 10. Unit turns itself off (and stays off) Very strange, but very consistent. The only "event" that disrupted the above behavior today was a power outage that lasted 2 hours. Once the power came back, all of the above behavior disappeared and the radio worked like it is supposed to. After a while, it was back to the "odd" behavior above. Any ideas or questions are welcome.
Wanted to update my prior post in the hopes that it helps to get this bug fixed. I don't want to speak too soon, but I now have had 24 hours of flawless listening to my Radio. No automatic turn offs; no turning on by itself. All of the odd behavior that I reported in my prior posts has been eliminated. How? The only thing I did was delete any alarms that were programmed (not just disable - DELETE). My radio now contains no alarms. There are no alarms set on MSB.com. I also redirected the radio to SBS and made sure there were not stray alarms there. Then I redirected the radio back to MSB.com Once alarms were deleted, I made sure that the "All Alarms" setting was set to "off". Then I did a power down by pulling the plug and re-plugging. No more auto turn offs, etc. Why? I have no idea but I'm convinced (for today) that the alarms were causing my problems. Who knows, tomorrow I may retract my statements.
I retract my last post. After 36 hours of flawless listening, the radio is back to its auto off, auto on behavior, exactly as I posted in my step by step details. I give up for now.
There may be multiple causes for these symptoms but it appears that one major cause has been identified. The server (mysqueezebox.com, aka SN) sends various status notifications to the player, in particular playerstatus and serverstatus. Both these notification types include information about the state of the player, including its soft power state (ON or OFF). Unfortunately, not all the information in serverstatus is guaranteed to be up-to-date. In fact, for the controlled player, only its 'connected' state is always accurate. Therefore, a player should not really take notice of plater-state information for itself included in a serverstatus notification (serverstatus will also include information about other connected players on the same account). It should rely only on the always-accurate information from playerstatus. If only life were that simple. A player only subscribes to playerstatus notifications once it is fully connected to the server. The trigger to proceed with the detailed steps involved in this process is only activated when it is discovered that the player is connected to the server, which is indicated in a serverstatus notification. Therefore, it is necessary to handle player-state information in a serverstatus notification when that information indicates a change in the connected status of the player. It is also also necessary to handle player-state information in a serverstatus notification when that information indicates that the current server for the player has changed. The code already contains checks (in the form of a hold-down timer) to deal with the possibility of obsolete information in a serverstatus notification when the player has been commanded to change server. The specific problem with using the obsolete player-state information from the serverstatus notification is that the power state can appear to change erroneously. The resulting internal notification in the player can stop playback (or possibly start it in the case of an erroneous ON notification), cancel alarms, change the screen state, etc. It is quite possible that these erroneous notifications could flip-flop back and forth in some circumstances. A temporary workaround, until such time as new firmware can be tested and released, would be to leave the player ON even when not in use. The Pause button can be used to stop audio output and a blank or clock screenserver (as desired) could be used in this state (Settings / Screen / Screensavers / When Stopped). I realise that this is far from ideal.
Created attachment 6913 [details] proposed patch
Having created this bug report originally my current situation is as follows. As a result of the bug report I was asked to return my radio for analysis and received a replacement unit. My new radio with identical settings and environment continues to work fine and does not display any of the original reported problems, so it was definately a hardware problem with that unit as far as I am concerned. My old radio was received by Logitech in Switzerland over a week ago. I have never set any alarms on either unit. I still often get a cut out within 10 sec of starting it with a preset and set it going again with 2 presses of the play button. After that it is OK - but that is another bug, a bit annoying but I can live with it. So in summary I am now happy with my SB Radio
*** Bug 16339 has been marked as a duplicate of this bug. ***
*** Bug 16224 has been marked as a duplicate of this bug. ***
*** Bug 16271 has been marked as a duplicate of this bug. ***
*** Bug 16368 has been marked as a duplicate of this bug. ***
== Auto-comment from SVN commit #8960 to the jive repo by ayoung == == http://svn.slimdevices.com/jive?view=revision&revision=8960 == bug 16295: SB Radio changes state & display on its own. Avoid using player state information for the current player from a serverstatus notification except under specific conditions: - when the state indicates a change in server; - when the state indicates a change in connected status.
(In reply to comment #20) > Created an attachment (id=6913) [details] > proposed patch After applying this patch (to firmware 7.6.0 r8934) the bug seems to be fixed, but there is a new bug introduced - when an alarm times out it just stops the stream instead of turning the radio off like the way it used to. Or was it an intended behavior?
(In reply to comment #27) > (In reply to comment #20) > > Created an attachment (id=6913) [details] [details] > > proposed patch > > After applying this patch (to firmware 7.6.0 r8934) the bug seems to be fixed, > but there is a new bug introduced - when an alarm times out it just stops the > stream instead of turning the radio off like the way it used to. I forgot to add - I only use mysqueezebox.com.
>> but there is a new bug introduced - when an alarm times out it just stops the >> stream instead of turning the radio off like the way it used to. Maybe that was intended and responsible for https://bugs-archive.lyrion.org/show_bug.cgi?id=16012 and https://bugs-archive.lyrion.org/show_bug.cgi?id=16325 ?? Just guessing
(In reply to comment #29) > >> but there is a new bug introduced - when an alarm times out it just stops the > >> stream instead of turning the radio off like the way it used to. > > Maybe that was intended and responsible for > https://bugs-archive.lyrion.org/show_bug.cgi?id=16012 and > https://bugs-archive.lyrion.org/show_bug.cgi?id=16325 > ?? > > Just guessing Hmm, maybe I haven't used the timeout feature of alarm and haven't noticed this (new?) behaviour in 7.5.1. Looking at what the patch changes this indeed seems to be totally unrelated.
I split off the issue about the Alarm timeout behavior to bug 16398. This bug is now resolved, meaning that if you try the 7.5.x or 7.6 beta server versions, you should no longer see it. We're currently testing the 7.5.x *firmware builds only* for an upcoming release if you'd rather wait. After that release, this will be marked 'closed.' If you have additional issues with this bug *in the beta builds where it should be fixed*, please re-open it. If you have related issues, please file a new bug. Thanks!
*** Bug 16329 has been marked as a duplicate of this bug. ***
This bug has now been fixed in a released version of the Squeezeplay firmware (SB Touch, SB Radio, and SB Controller). If you are still seeing this bug, please make certain you are running firmware 9009 or higher, and re-open it. Thanks!