*** This bug has been confirmed by popular vote. ***

I have been having this issue since 7.5 with all 4 of my Squeezeboxes.  The problem is very apparent with the use of Pandora -- which I use the most often.  I've also seen it with Sirius.  I use mysqueezebox.net and never had an issue prior to 7.5

http://forums.slimdevices.com/showthread.php?t=76938

@chris
thanks for splitting.

(In reply to comment #0)
> Split off from Bug 16046.
> 
> SBR with new FW 7.5 stops playing internet radio. the problem occurs with
> connection via mysqueezebox.net and via squeezebox server. it happens
> unregularly but around once an hour.
> when stopping sbr shows screensaver "not playing".

Radio stopped 4x within two hours this morning

This is also happening with Pandora and MP3tunes.com. Sometimes, after it stops playing, it goes back to playing the stream that I was listening to previously; for example, I listened to MP3tunes.com last night. This morning, I turned on Pandora and after a while it stopped playing. When it came back a couple of minutes later, it had gone back to playing my MP3tunes.com selection from last night.

Hello,

Ever since the 7.5 firmware upgrade I have been experiencing the same problems everyone on this bug report has been: 
1) Internet Radio stream either stopping or interrupting for 3-5 minutes while connected to the mysqueezebox.net. I have not installed the squeezebox server. 
2) The SBR will display the Alarm Clock when not asked to. 
3) Sometimes I have to disconnect power to reboot 
4) When I revert back to 7.4, power down the SBR and then power it back up , the 7.5 upgrade gets installed automatically without asking. 

I am using a NetGear router which is probably 6 years old but the 4 laptops I have connected to it do not expeience any problems when I am trying to listen to the SBR.

Could there be an incompatibility issue with my NetGear router ?? 

Finally, sometimes the disconnects happen frequently and there are some days when it happens once maybe twice. 

Thanks,
Rick

Please make sure to include what station you are listening to.  If it's happening with Pandora, please file a separate bug!  That's why I tried to be so specific in this bug title.

Thanks!

i've had issues like this ever since i got my SB2 way back in 04.

http://forums.slimdevices.com/showthread.php?t=78019

Since upgrading to 7.5, this happens most times I use the radio - I come out of standby, start playing an internet radio station or LastFM, then approx 1 minute later the radio will go back into standby or stop playing without me pressing anything.

Radio cuts out so much I can't use it anymore.  Now using my Ipad to stream internet radio stations.  Too bad, been a loyal user of the original squeezebox and bought the radio from logitech before the release.  Very disappointed in this product right now.

Created attachment 6820 [details]
The fail-to-play SBR reboot

Following on the reboot log I've just posted.
I've been reporting alarm problem for week (starting with 6.4.2 and getting worse with 7.5.0)

Yesterday I had an interesting situation, which make me think that the problem is maybe not related to the alarm, but to the player.

My Wifi network got overwhelmed by a bunch of downloads I had to do for my company. 
My laptop running a VPN session didn't have any problem.
My Wifi router is a Linksys WAG54GS.

But the SBRadio stopped and never resumed. 
At the end I decided to reboot (8:55), but it was no able to play my favorite radio: rtl-1-44-96.
I left it running like this for about 15 minutes (hoping it will resume by itself).
Then I pressed the play button again and the SBRadio started immediately.

Please keep in mind there's no alarm scenario in this log.
I've attached the full log in my previous posting.
Here's the interesting part (IMHO) with comments prefixed mith "PASCAL:"

May  3 08:54:32 squeezeplay: INFO   applet.SlimMenus - SlimMenusApplet.lua:441 _menuSink(23) SlimServer {mysqueezebox.com} menuDirective: nil isCurrentServer:true
May  3 08:54:32 squeezeplay: INFO   applet.SlimMenus - SlimMenusApplet.lua:713 hiding any 'connecting to server' popup after menu response from current server, SlimServer {mysqueezebox.com}
May  3 08:54:32 squeezeplay: INFO   applet.AlarmSnooze - AlarmSnoozeApplet.lua:239 notify_playerLoaded(LocalPlayer {Radio})
May  3 08:54:33 squeezeplay: INFO   applet.ChooseMusicSource - ChooseMusicSourceApplet.lua:543 Hiding popup, exists?: nil
May  3 08:54:33 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:260 notify_playerModeChange: player (LocalPlayer {Radio}) mode has been changed to stop
May  3 08:54:33 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:262 notify_playerModeChange: - audioState is 0
May  3 08:54:33 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:115 notify_playerAlarmState received for LocalPlayer {Radio} with alarmState of set
May  3 08:54:33 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:117 **************************** notify_playerAlarmState received: set 1272945600
May  3 08:54:33 squeezeplay: INFO   applet.AlarmSnooze - AlarmSnoozeApplet.lua:194 storing epochseconds of next alarm:  1272945600
May  3 08:54:33 squeezeplay: INFO   squeezeplay.applets - AppletManager.lua:708 store settings: AlarmSnooze
May  3 08:54:33 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:579 _stopTimer: stopping RTC fallback alarm timer
May  3 08:54:33 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:584 _stopTimer: stopping WOL timer
May  3 08:54:33 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:641 _startTimer: starting RTC fallback alarm timer (75937000)
May  3 08:54:34 squeezeplay: INFO   squeezeplay - JiveMain.lua:207 Turn soft power on
May  3 08:54:35 squeezeplay: INFO   applet.SlimMenus - SlimMenusApplet.lua:441 _menuSink(1) nil menuDirective: add isCurrentServer:true
May  3 08:54:35 squeezeplay: INFO   applet.SlimMenus - SlimMenusApplet.lua:713 hiding any 'connecting to server' popup after menu response from current server, SlimServer {mysqueezebox.com}
May  3 08:54:35 squeezeplay: INFO   applet.AlarmSnooze - AlarmSnoozeApplet.lua:239 notify_playerLoaded(LocalPlayer {Radio})
May  3 08:54:35 squeezeplay: INFO   applet.ChooseMusicSource - ChooseMusicSourceApplet.lua:543 Hiding popup, exists?: nil
May  3 08:54:35 squeezeplay: INFO   applet.SlimDiscovery - SlimDiscoveryApplet.lua:517 notify_playerPower: true
May  3 08:54:35 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:260 notify_playerModeChange: player (LocalPlayer {Radio}) mode has been changed to play
May  3 08:54:35 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:262 notify_playerModeChange: - audioState is 0
May  3 08:54:35 squeezeplay: INFO   squeezeplay.applets - AppletManager.lua:708 store settings: Playback
May  3 08:54:44 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:877 repeat button style changed to: repeatPlaylist
May  3 08:54:44 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:853 shuffle button style changed to: shuffleOff
May  3 08:55:00 squeezeplay: INFO   squeezebox.server - SlimServer.lua:714 disconnected EEE-PRO idleTimeoutTriggered: true
May  3 08:55:00 squeezeplay: INFO   squeezebox.server - SlimServer.lua:717 idle disconnected EEE-PRO
May  3 08:55:00 squeezeplay: INFO   applet.AlarmSnooze - AlarmSnoozeApplet.lua:310 notify_serverDisconnected: SlimServer {EEE-PRO} is now disconnected
May  3 08:55:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:323 notify_serverDisconnected: SlimServer {EEE-PRO} - disconnected, but no server alarm in progress : nil
May  3 08:55:09 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:877 repeat button style changed to: repeatPlaylist
May  3 08:55:09 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:853 shuffle button style changed to: shuffleOff
May  3 08:55:09 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:877 repeat button style changed to: repeatPlaylist
May  3 08:55:09 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:853 shuffle button style changed to: shuffleOff
May  3 08:55:10 squeezeplay: INFO   audio.decode - decode_start_handler:275 init decoder mp3

PASCAL: REQUEST for my 2nd favorite=franceinfo, cannot remind having pushed the "2" button
May  3 08:55:10 squeezeplay: INFO   audio.decode - Playback.lua:436 connect 213.205.105.129:80 GET /franceinfo HTTP/1.0^M
May  3 08:55:10 squeezeplay: INFO   audio.decode - Playback.lua:439 GET /franceinfo HTTP/1.0^M
May  3 08:55:10 squeezeplay: Accept: */*^M
May  3 08:55:10 squeezeplay: Cache-Control: no-cache^M
May  3 08:55:10 squeezeplay: User-Agent: iTunes/4.7.1 (Unix; N; linux; x86_64-linux; EN; iso-8859-1) SqueezeNetwork/7.5.1-sn/TRUNK^M
May  3 08:55:10 squeezeplay: Icy-MetaData: 1^M
May  3 08:55:10 squeezeplay: Connection: close^M
May  3 08:55:10 squeezeplay: Host: vipicecast.yacast.net^M
May  3 08:55:10 squeezeplay: ^M
May  3 08:55:11 squeezeplay: debug_pagefaults:192 Pagefaults, Major:0 Minor:2
May  3 08:55:16 squeezeplay: audio_thread_execute:908 xrun (snd_pcm_mmap_commit) err=-32
May  3 08:55:20 squeezeplay: debug_pagefaults:192 Pagefaults, Major:0 Minor:1
May  3 08:55:20 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:877 repeat button style changed to: repeatPlaylist
May  3 08:55:20 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:853 shuffle button style changed to: shuffleOff
May  3 08:55:20 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:877 repeat button style changed to: repeatPlaylist
May  3 08:55:20 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:853 shuffle button style changed to: shuffleOff

PASCAL: SELECTING WMA, why ? See next where not wma
May  3 08:55:24 squeezeplay: INFO   audio.decode - decode_start_handler:275 init decoder wma
PASCAL: GETTING info for my favorite "rtl-1-44-96"
May  3 08:55:24 squeezeplay: INFO   audio.decode - Playback.lua:436 connect 92.61.164.12:80 GET /rtl-1-44-96 HTTP/1.0^M
May  3 08:55:24 squeezeplay: INFO   audio.decode - Playback.lua:439 GET /rtl-1-44-96 HTTP/1.0^M
May  3 08:55:24 squeezeplay: Accept: */*^M
May  3 08:55:24 squeezeplay: User-Agent: NSPlayer/8.0.0.3802^M
May  3 08:55:24 squeezeplay: Host: 92.61.164.12^M
May  3 08:55:24 squeezeplay: Pragma: xClientGUID={f236c939-2e99-1b12-1761-0d866eb3ce45}^M
May  3 08:55:24 squeezeplay: Pragma: no-cache,rate=1.0000000,stream-offset=0:0,max-duration=0^M
May  3 08:55:24 squeezeplay: Pragma: stream-time=0^M
May  3 08:55:24 squeezeplay: Pragma: request-context=2^M
May  3 08:55:24 squeezeplay: Pragma: LinkBW=2147483647, AccelBW=1048576, AccelDuration=21000^M
May  3 08:55:24 squeezeplay: Pragma: Speed=5.000^M
May  3 08:55:24 squeezeplay: Pragma: xPlayStrm=1^M
May  3 08:55:24 squeezeplay: Pragma: stream-switch-count=1^M
May  3 08:55:24 squeezeplay: Pragma: stream-switch-entry=ffff:1:0 ^M
May  3 08:55:24 squeezeplay: ^M
May  3 08:55:24 squeezeplay: debug_pagefaults:192 Pagefaults, Major:0 Minor:1
May  3 08:55:26 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:877 repeat button style changed to: repeatPlaylist
May  3 08:55:26 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:853 shuffle button style changed to: shuffleOff
May  3 08:56:20 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {mysqueezebox.com_Request}(R))

PASCAL: PUSHED the PLAY Button
May  3 09:09:46 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 2.741 seconds
May  3 09:09:49 squeezeplay: INFO   net.slimproto - SlimProto.lua:599 connect to baby.squeezenetwork.com (89.202.121.131)
May  3 09:09:50 squeezeplay: debug_pagefaults:192 Pagefaults, Major:0 Minor:1
May  3 09:09:57 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:260 notify_playerModeChange: player (LocalPlayer {Radio}) mode has been changed to stop
May  3 09:09:57 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:262 notify_playerModeChange: - audioState is 0
May  3 09:09:57 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:877 repeat button style changed to: repeatPlaylist
May  3 09:09:57 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:853 shuffle button style changed to: shuffleOff
May  3 09:10:19 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 3.513 seconds
May  3 09:10:20 squeezeplay: INFO   applet.ScreenSavers - ScreenSaversApplet.lua:260 activating BlankScreen screensaver
May  3 09:10:23 squeezeplay: INFO   net.slimproto - SlimProto.lua:599 connect to baby.squeezenetwork.com (89.202.121.131)
May  3 09:10:59 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {mysqueezebox.com_Request}(R))

PASCAL: Selecting mp3 !
May  3 09:11:09 squeezeplay: INFO   audio.decode - decode_start_handler:275 init decoder mp3
May  3 09:11:09 squeezeplay: INFO   audio.decode - Playback.lua:436 connect 92.61.164.12:80 GET /rtl-1-44-96 HTTP/1.0^M
May  3 09:11:09 squeezeplay: INFO   audio.decode - Playback.lua:439 GET /rtl-1-44-96 HTTP/1.0^M
May  3 09:11:09 squeezeplay: Accept: */*^M
May  3 09:11:09 squeezeplay: Cache-Control: no-cache^M
May  3 09:11:09 squeezeplay: User-Agent: iTunes/4.7.1 (Unix; N; linux; x86_64-linux; EN; iso-8859-1) SqueezeNetwork/7.5.1-sn/TRUNK^M
May  3 09:11:09 squeezeplay: Icy-MetaData: 1^M
May  3 09:11:09 squeezeplay: Connection: close^M
May  3 09:11:09 squeezeplay: Host: 92.61.164.12^M
May  3 09:11:09 squeezeplay: ^M
May  3 09:11:09 squeezeplay: debug_pagefaults:192 Pagefaults, Major:0 Minor:1
May  3 09:11:10 squeezeplay: debug_pagefaults:192 Pagefaults, Major:0 Minor:1
May  3 09:11:11 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:260 notify_playerModeChange: player (LocalPlayer {Radio}) mode has been changed to play
May  3 09:11:11 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:262 notify_playerModeChange: - audioState is 1
May  3 09:11:11 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:877 repeat button style changed to: repeatPlaylist
May  3 09:11:11 squeezeplay: WARN   applet.NowPlaying - NowPlayingApplet.lua:853 shuffle button style changed to: shuffleOff
May  3 09:12:08 squeezeplay: WARN   net.thread - NetworkThread.lua:146 network thread timeout for Task(SocketHttp {mysqueezebox.com_Request}(R))

Like others I am experiencing the problem of the radio stopping when playing internet radio (e.g. BBC Radio 4). Hitting the preset will sometimes restart it but mostly not. To get it going again I have to hit another preset, then when that is going, hit the first again. When not playing it dispalys the "stopped" screensaver.

But also not reported by others when turned off it often turns itself on again, dispalying the menu or "now playing" screen for 10 secs (my screensaver delay) then the "stopped" screensaver.n.b. it does not start playing the radio station, it is in the stopped state.

i.e. my radio appears to have an aversion to being in anything other than the stopped state, so it keeps returning to it from either "playing" or "off"

I am running 7.5.0 r8673 against mysqueezebox.com. It worked perfectly before the automatic "upgrade" to 7.5. For a consumer product this is not good enough!

(In reply to comment #14)
> Like others I am experiencing the problem of the radio stopping when playing
> internet radio (e.g. BBC Radio 4). Hitting the preset will sometimes restart it
> but mostly not. To get it going again I have to hit another preset, then when
> that is going, hit the first again. When not playing it dispalys the "stopped"
> screensaver.
> 
> But also not reported by others when turned off it often turns itself on again,
> dispalying the menu or "now playing" screen for 10 secs (my screensaver delay)
> then the "stopped" screensaver.n.b. it does not start playing the radio
> station, it is in the stopped state.
> 
> i.e. my radio appears to have an aversion to being in anything other than the
> stopped state, so it keeps returning to it from either "playing" or "off"
> 
> I am running 7.5.0 r8673 against mysqueezebox.com. It worked perfectly before
> the automatic "upgrade" to 7.5. For a consumer product this is not good enough!

I can confirm this same behavior on my radio. It often turns off shortly after starting to play various stations (Pandora, SKY.FM Shoutcast, local streaming radio, etc.) and can't resume playback until playing another station first.

And it often turns itself back on and waits in the "stopped" state exactly as described. This behavior all started with the last firmware update.

Today, less than a minute after I set "my station" last.fm (through mysqueezebox.com) playing by pressing a favortie button, the Radio dropped to the "stopped" clock and stopped playing. Usually, I would give it a poke on the "Play" button to get it going again, but this time, mindful of some of the comments on the Forums that mentioned that things continued to happen, I did not set it playing again immediately. 

After about a minute or two with the "stopped" clock in place, the album art for the track that had been playing reappeared, but with no sound. The names of the tunes on the track continued scrolling across the top of the screen, but no sound. After about 10 minutes of this I pressed the play button and "my station" happily resumed playing with a new track and "my station" has now been playing for an hour without further interruption.

The dropping has occurred for me so far on C-SPAN radio, Vermont Public Radio, last.fm. As soon as I have a moment, I will load Squeezebox Server on my new computer and learn how to download logs so that I can help you with the bug sleuthing. (Who knew that I would have to become the Grandma Moses of techies? I did not realize when I bought this new "simple" clock radio that it was actually a device used to keep Alzheimer's at bay. You should tell Logitech marketing.)

Update on my previous comment: I have had last.fm (from mysqueezebox.com) playing now without pause for about 3 hours. Although there has not been a drop to "Stop", a couple of time a strange thing has happened which I never noticed before so I can't say if it is new or whether it has been happening right along. Several times a new track will start to play for a couple of seconds only (just a few notes) and suddenly another track will start up and that new track will continue to play to the end and the whole thing will go on as though nothing had happened.

It is as though I had zipped over to the Radio and pressed the FF button which on last.fm operates to send it to another track. 

I don't know whether this is manifestation of this bug or whether it is some issue with last.fm trying to play a banned track and then getting its wits together. The track is aborted so suddenly that I don't have time to identify the the track. My guess is that it is related to the bug, because I think that before one of the drops I heard the uilleann pipes of which (despite some opinions to the contrary) I am particularly fond and would have been unlikely to have banned.

Firmware ver: 7.5.0-r8673
Internet connection has 50-100ms latency,
Internet connection has sustained 5 Mbps and burst to 25 Mbps. Tested and verified.

Has a history of shutting radio off, especially right after it has come on.

MySqueezebox.com remote control shows the radio as playing, but it is not. If I press pause then play, it instantly starts playing. (same results on mysqueezebox.com remote or on the physical unit itself)

Have tried buffering from 8 to 30 seconds, makes no difference.

It appears to get confused because it comes back on instantly, it does not go through the buffering sequence.

This also happens with the alarm set to radio. Radio comes on (maybe), then it reverts back to an internal sound effect or turns off...but it is really not off, looking at mysqueezebox.com Internet remote shows that it is playing music. pressing pause then play brings it back instantly.

I have put it on a dedicated connection directly connected to the Internet, reset to factory defaults and updated the firmware several times.

Reverted to 7.4.2 a while back and radio seems OK except for constant update reminders-which I could get rid of (temporarily)by pressing HELP then HOME then NOW PLAYING. Now getting another problem with radio only playing a few seconds after start-up then stopping to clock. The left bottom play arrow often remains in stop position (solid square instead of arrow head). Again a solution seems to be to change stations - I go to pandora or something - the the radio seeks, buffers and then plays OK.
I love this radio when it plays, but I must admit these constant problems are getting pretty irritating. My wife won't use it on her own anymore and I would not recommend it at this time to anyone. At least not this brand.

Can anyone advise if anything is being done to resolve this?  

We've heard nothing about the issue being resolved, and to add insult to injury, Support is also sending me emails that they are ready to close the ticket because they assume it's been resolved (?).

This is obviously a very widespread issue that is all over not only Logitech's Forum, but all over the Web.  People no longer are using these due to issues with the 7.5 release.

Can someone please provide an update?

(In reply to comment #20)
> Can anyone advise if anything is being done to resolve this?  
> 
> We've heard nothing about the issue being resolved, and to add insult to
> injury, Support is also sending me emails that they are ready to close the
> ticket because they assume it's been resolved (?).
> 
> This is obviously a very widespread issue that is all over not only Logitech's
> Forum, but all over the Web.  People no longer are using these due to issues
> with the 7.5 release.
> 
> Can someone please provide an update?

They are ready to close the ticket?? Have they seen the latest reviews on Amazon? The radio is basically unusable with 7.5, I can't believe they are not aware of this.

I have the same issue after upgrading to 7.5.
I have two Duets and one Squeezebox Radio.  It is the same on all three.
I have been able to witness this problem on most of the most common radio stations I am listening to: Metro (finnish), Aalto (finnish) and DR P3 (Danish).  It stops playing typically after 10-20 min.
The Internet Radio has been working great before 7.5.
Everything else works fine, for instance playing music from my music library.

Radio stops playing Internet Radio

** This is in continuation of my post.

Squeezebox Radio stops playing Internet Radio after 30 minutes or so.  Needs to power cycle the Squeezebox Radio to get it playing again.

i think this bug should have this other bug listed as a block or depends on:

https://bugs-archive.lyrion.org/show_bug.cgi?id=3161

Please make sure to post what radio station you are listening to, thanks!

(In reply to comment #26)
> Please make sure to post what radio station you are listening to, thanks!

I have this problem with my Squeezebox Radio, firmware 7.5, when listening to Sveriges Radio P1 (Sweden). It often stops playing after only a minute or so.

Stopped this morning after ~20 minutes listening to KTCK Sports Talk out of Dallas. But really, I'm pretty sure it happens with everything, including Mediafly and Rhapsody. I'll try to pay closer attention.

The dropping manifestation has changed for me. Before it would drop at a random interval any time it was playing--hour, half-hour. Now once it gets up and going, it seems pretty stable. I have not had a later drop in a long time.

Currently, it nearly always (but not 100% of the time) will drop the station within about 15-30 seconds after I turn it on from standy (the clock). The sound stops and the screen goes to the standby clock. If I press the play button once it will not start again, but if I press it twice it starts up instantly--just as though it had been on pause. This happens with Vermont Public Radio, C-SPAN Radio, Last.fm, Podcasts. At least once it happened when I was still on the home menu, before I even got as far as choosing my station. I have got in the habit of just pressing any preset and waiting for the Radio to drop the station and getting it up and going again before choosing the station I am actually planning to listen to.

The alarm also manifests this same problem. It will come on to the desired radio station--Vermont Public Radio--for a brief moment and then it will drop the station and in another moment, the backup alarm music will come on. (I can't say what would happen next because the backup alarm is so loud and horrible that I turn it off instantly. Flesh and blood can only stand so much in the cause of science.)

I am still using the official FW 7.5. It is interesting that gorgonzola@email.com who has rolled the FW back to 7.4.2 has described the same problem. That suggests to me that this problem may be with mysqueezebox.com.

I'm experiencing the EXACT same symptoms as described by mpower in #29. Drop-out within 30 secs on both radio and alarm, and this is a fairly new wrinkle (last week or two?).

(In reply to comment #29)
> I am still using the official FW 7.5. It is interesting that
> gorgonzola@email.com who has rolled the FW back to 7.4.2 has described the same
> problem. That suggests to me that this problem may be with mysqueezebox.com.

That's an interesting theory, and makes sense to me. When I first upgraded to FW 7.5 I didn't have any problems with dropped audio. That didn't start until a week or so after my upgrade. I figured that I must have just not noticed it at first... but maybe it doesn't have anything to do with the Firmware version. I have two SB Radios using mysqueezebox.com and they both frequently experience dropped audio within about 30-60s of starting to play a stream (happens with lots of different streams.) I'll have to switch to Squeezebox Server and see if the problem persists.

update: Just as described above. I'm still on 7.4.2 and recently I lose my connection just about every time I start the radio up. If I use presets or the on button+play internet radio stream stops and goes to clock within 10-20 seconds. This is new behavior. After re-start(it seems to help to force a new seek action by changing stations or by using FWD button)the radio will play OK except for the periodic update nag.
I've never used this Bugzilla system to report product problems before, but it almost seems designed give us consumers the run around. I talked to service reps and reported here - all seemingly to no avail. I'm just waiting to see this "ticket" show resolved status - but no faith that our problems will be indeed be fixed!

It really is pretty outrageous that this bug causing stations to drop, making the squeezebox all but unusable, has not been fixed after all this time - and it happens on every station that I usually listen to (WQXR, WFUV, KCRW, NJN, WEOS, KUSC).

I think the 5.0 version should be withdrawn and allow the return of 4.2. Whatever bug 5.0 was supposed to fix couldn't possibly be worse than this! At least give us the option of refusing the so-called upgrade. Now, if I revert to the older version, the Squeezebox keeps trying to update - and eventually does when I reboot.

Still no confirmation or status update from Logitech? What's going on here? It's obvious this isn't an isolated occurrence. Logitech, please let us know what's going on. At least let us know that you're aware of this and working on a resolution ASAP. Thank you!

Hi.  we have been looking into this issue but it is not clear what the problem is, and it is difficult for us to reproduce.  If you can reproduce this with Squeezebox Server, it would be helpful to enable the following debug settings in the server and attach a log:

player.source (INFO)
player.streaming.direct (DEBUG)
scan.scanner (DEBUG)

Created attachment 6838 [details]
Radio playing BBC4 log

Possible reproduction of issue with Radio on firmware f8673 connected only to MySB.com, no Squeezebox Server. Playing BBC4 internet radio stream, and internet connection was disrupted momentarily. Pressed Play to restart, and no BBC4 audio heard. Audio from scrolling in menus is OK.

When enabled logging for audio.* and net.slimproto, Now Playing screen has 99.9%/98.2% on bottom; these percentages aren't changing.

Have two other Radios playing SR P3 (Stockholm, Sweden) and Slacker station when internet was interrupted. Both stopped playing audio, but restarted audio immediately when Play was pressed.

Log for Radio playing BBC4 attached.

After I entered Comment 36, I notice the Radio stuck on BBC showed the Now Playing screen with a stop icon on the bottom left. Previously, it was blank. I also noticed the percentages had changed. I pressed Play and I started hearing BBC4 again.

From looking at the Touch screen next to these Radios, it appears that the internet connectivity was momentarily disrupted again. Somehow this second disruption kick started it again.

Created attachment 6840 [details]
Log of possible reproduction of issue playing SR P3 99.3 Stockholm

Happened again with different Radio with different internet radio stream. Percentages on Now Playing show 100.0%/98.2%.

I am not convinced I am seeing the same issue as others are seeing. Can others who are seeing this issue turn go to Settings->Advanced->Logging and scroll down to set these values:

audio.codec to Debug
audio.decode to Debug
audio.output to Debug
net.slimproto to Debug

(Scroll down to the item listed above and press the big knob repeatedly until the value is Debug)

When you do this, the Now Playing screen will replace the time in the middle of the bottom row with two percentage values. When someone sees this again, can you be sure to report back in this bug what values you see and whether they're constantly changing? That would be super helpful.

Observing same behavior as everyone else: internet radio stops randomly.  Also occasionally on startup the SB does not find DNS.

Have an old Linksys WRT54G router, but everything else works fine on it.

SBR repeatedly hangs while playing via mysqueezebox.net.  FW 7.5.0-r8673

(In reply to comment #29)
> The dropping manifestation has changed for me. Before it would drop at a random
> interval any time it was playing--hour, half-hour. Now once it gets up and
> going, it seems pretty stable. I have not had a later drop in a long time.
> 
> Currently, it nearly always (but not 100% of the time) will drop the station
> within about 15-30 seconds after I turn it on from standy (the clock). The
> sound stops and the screen goes to the standby clock. If I press the play
> button once it will not start again, but if I press it twice it starts up
> instantly--just as though it had been on pause. This happens with Vermont
> Public Radio, C-SPAN Radio, Last.fm, Podcasts. At least once it happened when... 
> 
> ...I am still using the official FW 7.5. 

Same thing here. I am listening to the German Radio Station SWR3 via MySB.com

After tuning to the station from StandBy Clock the Radio stops playing after 15-30 seconds. Pressing Play again starts the Radio again and the it is pretty much stable.
Howether it seems to have a live of its own sometimes. Several times after I had set the radio to the StandBy clock I noticed some time later that it has switched itself on and the now playing screensaver was visible. But the Radio itself was not playing.

Created attachment 6841 [details]
log from when last.fm stopped playing

I had a last.fm stream running trying to reproduce this.

Radio running 7.5.1 r8746
Connected to mysb.com directly
logging: audio.*, net.slimproto, squeezebox.player and squeezebox.server all set to DEBUG

Log shows a couple things--
a showbriefly attempts to come to screen and fails to via the displaystatus mechanism in Player.lua because of an 'invalid client' error. That's very puzzling and could be a pointer to the root issue.
both DECODE UNDERRUN and AUDIO UNDERRUN messages are later reported in the log

Good log, that might be the issue.  Slimproto disconnects right around the time the track ended.

I have only avoided this as an ongoing issue by running 7.4.2 SBServer. It caused a prompt from the radio to downgrade the radio from 7.5 to the server's 7.4.2, which was uneventful. The server is not an ideal solution - the radio should JUST WORK. But it has given me constant internet radio, just like I thought I'd get when I bought the SqueezeBox Radio.

From Ben's log (comment #42):

It all goes wrong starting at 17:02. At that time there are various network disconnect events. More on that later. The result is that playing stops.

At 17:02:04, 18:34:46 and 19:03:13 the Slimproto connection is broken. In each case it is broken a second time a few seconds (13 - 33) later.

I suspect, if these are a general phenomenon, that these regular and multiple disconnects are at the heart of the problem.

In the 17:02 case, where playing was actually happening when the first disconnect happened, the unfortunate coincidence was that the STMd (DECODE UNDERRUN) event occurred while the connection was lost and before it was reestablished, presumably leading to the STMd being discarded.

StreamingController state machine will not react properly if the STMd event is lost. When the STMo event comes in later, it just assumes that the new strm-s command has already been sent but the autostart buffer threshold has not yet been reached.

This all could explain why things go wrong with lastfm, napster, etc. But not, as far as I can see, with normal radio stations.

I had two Babys playing RP connected to SN yesterday. One rebooted yesterday evening but the log from overnight is still interesting.

There is a high degree of correlation between the disconnect events. Too close, I'd say, to indicate that they were initiated by the players themselves, although it is possible that my local network infrastructure is implicated. However, given similar experience by Ben, I'd say not.

Timestamps are UTC+0200

BlackBaby:
May 17 00:15:14 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 4.453 seconds
May 17 05:47:31 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 4.377 seconds
May 17 05:47:45 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 2.935 seconds
May 17 05:53:38 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 2.566 seconds
May 17 05:53:52 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 1.397 seconds
May 17 06:17:25 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 1.052 seconds
May 17 06:17:26 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 3.544 seconds
May 17 06:17:47 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 4.112 seconds
May 17 06:48:22 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 2.851 seconds
May 17 06:48:44 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 4.19 seconds
May 17 07:11:37 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 3.649 seconds
May 17 07:11:50 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 4.329 seconds
May 17 07:11:54 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 1.14 seconds
May 17 07:11:55 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 1.46 seconds
May 17 07:12:04 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 1.28 seconds

BatteryBaby:
May 17 00:15:21 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 1.696 seconds
May 17 05:47:30 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 4.596 seconds
May 17 05:47:44 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 4.376 seconds
May 17 05:53:38 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 4.809 seconds
May 17 05:53:53 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 4.308 seconds
May 17 06:17:25 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 2.186 seconds
May 17 06:17:27 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 3.618 seconds
May 17 06:17:45 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 2.406 seconds
May 17 06:48:24 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 3.194 seconds
May 17 06:48:39 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 3.6 seconds
May 17 07:11:36 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 2.353 seconds
May 17 07:11:39 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 1.996 seconds
May 17 07:11:51 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 3.64 seconds
May 17 07:11:55 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 2.169 seconds
May 17 07:12:12 squeezeplay: INFO   net.slimproto - SlimProto.lua:773 connection error: closed, reconnecting in 4.485 seconds

Created attachment 6842 [details]
Proposed patch for status-packet-loss issue

The attached patch is untested. The idea is to wait until the slimproto connection is reestablished before sending any status notification. This could mean that some decode/output actions associated with the status change are also delayed.

 == Auto-comment from SVN commit #8775 to the jive repo by ayoung ==
 == http://svn.slimdevices.com/jive?view=revision&revision=8775 ==

bug 16170: SB Radio Internet Radio streaming stops unexpectedly 
Once a player has been stopped after a reboot following a crash, unsubscribe from
playerNew notifications so that any such notifications generated as a result of 
subsequent Comet reconnections do not erroneously stop playback.

Change to fix the fix for bug 10064 on SN has changed the symptoms slightly when internet interruption occurs:

- This issue not reproduced (yet) on Squeezebox Touch
- On 3 Squeeezbox Radios, two encountered "bump" when pressing Play (Stockholm 99.3 and BBC4), and one restarted Playing audio OK when it switched to Stop mode. For two with bump, percentages on screen were 100.0%/98.2% and 99.9%/98.2%, respectively.

Unfortunately, available logs document post-failure events.

Created attachment 6849 [details]
Log of attempt to unstick from Now Playing "bump" after issue occurred

Tried to workaround issue in Comment 49 with "bump" heard on Radio playing BBC4. I did a Power OFF/ON cycle but no change. Saw percentages on left increase, but not those on right. Not sure if log is helpful, but including them.

(In reply to comment #49)
> Change to fix the fix for bug 10064 on SN has changed the symptoms slightly
> when internet interruption occurs:

Mickey, I don't understand what you mean with this. bug 10064 was fixed in 7.5.0

Mickey, ok, I understand now.

How did you provoke the situation in comment #49?

I presume that this was just a soft Power OFF/ON cycle?

The workaround would be to Stop (press-hold Pause), then Play. Does this not work?

 == Auto-comment from SVN commit #30779 to the slim repo by ayoung ==
 == http://svn.slimdevices.com/slim?view=revision&revision=30779 ==

bug 16170: 
Notification handlers that need the Client object for a request need to check that it is valid before proceeding.

Created attachment 6850 [details]
Log file, with bump

New test with 4 Radios. All lost internet connection simultaneously. I went to Now Playing screen for all 4. Here's what happened:

- Two Radios got "bump" when Play pressed. Both were able to exit this state once I held down Pause and Now Playing had a Stop icon appear in the bottom left corner. I didn't know you could hold down Pause to get into Stop state. Don't think most users know this either and would not be able to continue once in this state.
- Two Radios were in stopped state with Stop icon appearing in the bottom left. Pressed Play and both restarted.

Adding two attachments -- Log for "bump", and log for no bump.

Created attachment 6851 [details]
Log file with no bump. Debug enabled.

It looks like the root of this bug is an interruption in internet connectivity which results in stopping of the radio stream.

So far, what happens is (using Radio as an example):

1. Radio goes into Stop mode, as seen by square Stop icon on Now Playing screen. Pressing Play resumes radio stream.
2. Radio goes into Pause mode, which is not obvious since Now Playing screen shows Play icon. User must hold down Pause button to switch to Stop mode and follows Step 1 above to resume radio stream.

I would think that it's desirable to have the following occur when connectivity is interrupted:

1. Radio continues playing from buffer.
2. In the meantime, it continues to reestablish internet connectivity with radio stream.
3. If buffer drops to zero percent, Radio goes into Stop mode.
4. If connectivity re-established, Radio goes back to filling buffer as normal.

I do not think it's desirable to go into Pause mode.

Created attachment 6852 [details]
Another log file with bump

Attaching log of another situation where a Radio was playing SR Atlas Stockholm radio station and stopped due to unknown reasons. Other Radios on same wireless network did not stop, so I'm guessing it's a problem that only this Radio encountered.

Radio went into Pause mode and restarted after holding down Pause and pressing Play.

The drop has been happening regularly a few seconds after start up from standby
and the screen saver returns to standby. 

When I press the Play arrow button, the screen saver returns to Now Playing and
the little status icon at the bottom of the screen shows the Pause icon (two
vertical parallel lines). If I press the Play button again. The station will
resume playing.

Created attachment 6853 [details]
One more "bump" log

Last log for now -- Radio playing SR P3 Stockholm. Stopped playing audio by itself, had to hold down Pause button to switch to Stop mode. Restarted OK.

Log looks like it lost connection to mysb.com. Other Radios next to it were OK and did not stop audio playback.

About Mickey's last comment: "Log looks like it lost connection to mysb.com."
Why do we stop playing in such situation ?
Why do we even always need mysb.com ? 
Couldn't we cache information needed (at least for the 6 predefined radios and alarms) so we only rely on the radio's server (only 2 equipements out of 3 would reduce chances to fall into a problem) ?

Unfortunately, none of the last three 'bump' logs show the start of the incident. That is, they do not show the details of what triggered the problem.

Created attachment 6855 [details]
Revised SP patch

The previous patch was flawed because it was easy for status packets to get lost when it was not known that the connection was about to go bad.

This patch takes a different approach: upon reconnection it resends any important status packets that may have been lost.

This patch also fixes up much of the reconnect handling at the slimproto level. Mostly this was not implemented or implemented incorrectly.

Created attachment 6856 [details]
Revised patch

Typo in previous patch

Had 3 Radios with firmware 7.5.1 r8777 playing overnight, connected to MySB.com only. 2 playing SR P3 Stockholm, 1 playing SR Atlas Stockholm. All 3 ended up in pause mode, with the Play icon showing at the bottom left corner. All were stuck with percentages like 97.8%/98.2%, 98.3%/98.2%.

Could resume play on all 3 by holding down Pause button to switch to stop mode, and then pressing Play button to resume stream.

Instigating incident had long passed, so nothing from logs.

Created attachment 6857 [details]
Revised patch

Remove incorrect cut-and-paste documentation from header.
Fix STMo/STMu mix-up in _reconnect().

 == Auto-comment from SVN commit #8789 to the jive repo by ayoung ==
 == http://svn.slimdevices.com/jive?view=revision&revision=8789 ==

bug 16170: SB Radio Internet Radio streaming stops unexpectedly 
Remove incorrect documentation from Slimproto.lua

Testing with firmware 7.5.1 r8789 with 3 Radios, one Touch connected to test SN servers. Test servers set up to kill connection every 15-30 minutes. With 36 hours of testing for Radios and 24 hours for Touch, had one Radio go to Stop mode and two Radios continue playing internet radio station. Touch still playing. Can watch players stop playing when connection is killed, and then watch them re-establish connection and resume playing automatically.

Going into Stop mode possibly OK, since it will restart playing by pressing Play instead of holding down Pause key or other uncommon workaround.

Will continue testing with additional logging.

Here is a status report for those monitoring this bug:

When 7.5.0 was released there was both new firmware for Squeezebox Radio and new software on mysqueezebox.com. People started reporting that their SB Radios stopped playing and many attributed this to problems to the 7.5.0 firmware. It seems highly likely that the actual cause was a bug introduced in to the mysqueezebox.com software. This bug was fixed on 17 May. Since then, behaviour should have reverted to that of 7.4.2. This is the key message in this comment.

In the process of analysing the problems, we uncovered a number of vulnerabilities in the interactions between a player and mysqueezebox.com which could, under some circumstances, cause playback to stop unnecessarily. The SB Radio (and other SP-based players including the SB Touch) is slightly more likely to be affected by these than are older players (Classic, Boom, Duet, etc.) because of small differences in timings used by the firmware. We also uncovered a couple of related bugs in the SP firmware. None of these are changes between 7.4.2 and 7.5.0.

Testing is currently under way for changes to both mysqueezebox.com and the firmware used for Radio and Touch to fix the identified bugs and substantially reduce the vulnerabilities. These fixes will be included in 7.5.1 and should represent an enhancement over 7.4.2 in this area.

(In reply to comment #68)
> Here is a status report for those monitoring this bug:
> 
> When 7.5.0 was released there was both new firmware for Squeezebox Radio and
> new software on mysqueezebox.com. People started reporting that their SB Radios
> stopped playing and many attributed this to problems to the 7.5.0 firmware. It
> seems highly likely that the actual cause was a bug introduced in to the
> mysqueezebox.com software. This bug was fixed on 17 May. Since then, behaviour
> should have reverted to that of 7.4.2. This is the key message in this comment.
> 
> In the process of analysing the problems, we uncovered a number of
> vulnerabilities in the interactions between a player and mysqueezebox.com which
> could, under some circumstances, cause playback to stop unnecessarily. The SB
> Radio (and other SP-based players including the SB Touch) is slightly more
> likely to be affected by these than are older players (Classic, Boom, Duet,
> etc.) because of small differences in timings used by the firmware. We also
> uncovered a couple of related bugs in the SP firmware. None of these are
> changes between 7.4.2 and 7.5.0.
> 
> Testing is currently under way for changes to both mysqueezebox.com and the
> firmware used for Radio and Touch to fix the identified bugs and substantially
> reduce the vulnerabilities. These fixes will be included in 7.5.1 and should
> represent an enhancement over 7.4.2 in this area.

Thank you for the update! This is great news and very encouraging! Keep up the good work.

Hi Alan,

Yes, this is excellent news.

During the last week it seemed to have improved significantly. I actually first thought it might have related to upgrading the software of my Netgear router - but maybe reality it relates to the fixes at mysqueezebox.com

Glad your are working on this and taking the problem seriously.

Cheers,
Jesper

(In reply to comment #68)
> Here is a status report for those monitoring this bug:
> 
> When 7.5.0 was released there was both new firmware for Squeezebox Radio and
> new software on mysqueezebox.com. People started reporting that their SB Radios
> stopped playing and many attributed this to problems to the 7.5.0 firmware. It
> seems highly likely that the actual cause was a bug introduced in to the
> mysqueezebox.com software. This bug was fixed on 17 May. Since then, behaviour
> should have reverted to that of 7.4.2. This is the key message in this comment.
> 
> In the process of analysing the problems, we uncovered a number of
> vulnerabilities in the interactions between a player and mysqueezebox.com which
> could, under some circumstances, cause playback to stop unnecessarily. The SB
> Radio (and other SP-based players including the SB Touch) is slightly more
> likely to be affected by these than are older players (Classic, Boom, Duet,
> etc.) because of small differences in timings used by the firmware. We also
> uncovered a couple of related bugs in the SP firmware. None of these are
> changes between 7.4.2 and 7.5.0.
> 
> Testing is currently under way for changes to both mysqueezebox.com and the
> firmware used for Radio and Touch to fix the identified bugs and substantially
> reduce the vulnerabilities. These fixes will be included in 7.5.1 and should
> represent an enhancement over 7.4.2 in this area.

 == Auto-comment from SVN commit #8815 to the jive repo by ayoung ==
 == http://svn.slimdevices.com/jive?view=revision&revision=8815 ==

bug 16170: SB Radio Internet Radio streaming stops unexpectedly 
We can only resume a stream (reconnect) if we already started decoding it.
Otherwise ignore the reconnect bit from the server.

I wanted to report that I have been running 7.5.1-r8805 on my production server for three days now and haven't had a single instance of the Radio dropping its connection. 

My issue was slightly different from what the majority have reported in this bug and on the forums - my Radio was regularly failing to reconnect following WOL at the server (but only once or twice dropped the connection during playback).

Either way the failing to connect on WOL issue (so far) appears to be fixed for me with the new firmware.  I'm also using a Netgear router so it may be that something in the firmware of the router is a bit more sensitive to the timing issues mentioned above.

Today, when I turned on the radio by using a preset button it started to play the radio station ("Polskie Radio PR3") but stopped after 15-30 seconds and turned itself down (standby). After another few seconds the "Now playing" screen came up again, with a "Play" icon in the lower-left corner but the radio was not playing. It could only be resumed after stopping it first.

I'm attaching the log starting right after pressing the preset button.

7.5.1 r8785.

Created attachment 6867 [details]
"Polskie Radio PR3" starts and the radio goes into standby after 15-30 seconds

This is the attachment to comment #73.

We have a ton of fixes in for this problem in 7.5.1.  Anyone who uses a local server should try the beta if you aren't already!

I'm going to leave the bug open for now against a hypothetical 7.5.2 release in case some users are still having problems after the 7.5.1 release.

Created attachment 6882 [details]
Radio stopped after 10-15 seconds with fw 8837

The same thing as in my comment 73 happened today with the latest firmware (8837) while connected to mysb. At around 7:02 I used the preset button to start the radio (starting from standby state). The radio played for 10-15 seconds and then turned itself off (i.e. went into standby). A few moments later the Now Playing screen was shown again, with the play icon in the lower-left corner but nothing was being played.

After the fixes to MySqueezebox.com were announced on 5/25, the problem seemed to go away for me. I didn't have any more problems for probably about a week or so. But since that time, I've had playback stop probably at least 5-6 times on two different Radios connected to MSB.com. It's not happening as frequent as it was before, but it's still occasionally happening.

(In reply to comment #77)
> After the fixes to MySqueezebox.com were announced on 5/25, the problem seemed
> to go away for me. I didn't have any more problems for probably about a week or
> so. But since that time, I've had playback stop probably at least 5-6 times on
> two different Radios connected to MSB.com. It's not happening as frequent as it
> was before, but it's still occasionally happening.

That's exactly how it looks now on my side. The frequency has dropped a lot (and no more default grey clock as screensaver) but it still does happen.

After updating firmware to 7.5.1-8837 internet radio stops playing on average once an hour. When it happens, a clock is showing. Pressing the preset for the station will start playing immediately (no buffering needed)

Pre 7.5 firmwares did not have this issue.

(In reply to comment #79)
> After updating firmware to 7.5.1-8837 internet radio stops playing on average
> once an hour. When it happens, a clock is showing. Pressing the preset for the
> station will start playing immediately (no buffering needed)
> 
> Pre 7.5 firmwares did not have this issue.


I have been trying out lots of things to solve this. And I have stumbled on a clue. 
The problem is a lost connection, as pointed out by many before.

In desperation I tried tinkering with my wireless router. Tried many different settings to no avail. 

Then I switched cipher from AES to TKIP. Since then the SB radio has played without stop.

Maybe the root of the problem is not the AES cipher, but is only worsened by it, maybe because it requires more processing power. But there is a clear improvement in using TKIP instead of AES. Saturday I had 8-10 streaming stops, today zero so far.

The problem is not in the router, since my two laptops, mac mini, and surround receiver all streams radio on both ciphers. It is only the SB Radio that struggles. (Ironic actually, since it is the one product I own, that was bought specifically for streaming radio...)

Someone should really start testing using cabled ethernet vs wireless (TKIP and AES).

Hope this helps in sorting the problems out. The Squeezebox forums are swarming with people with this sort of problem! I seriously hope there is someone working on this! It is pathetic to have a product that fails at the very funtionality hinted in its name : Squeezebox RADIO ;)

/Lars

I did some very simple (and probably not very accurate) measurements using top and compared AES vs. TKIP cipher with an SB Radio connected to a Netgear WGR614L. I was listening to a Pandora station i.e. MP3 128kbps CBR.

AES:
wpa_supplicant : 0%
AR6K (wlan driver) : 0-1% (3-4% while changing tracks)

TKIP:
wpa_supplicant : 0%
AR6K (wlan driver) : 0% (3% while changing tracks)

This suggests that using a AES cipher causes the wlan driver to slightly use more processing power.

P.S. I need to add that with either cipher my SB Radio did _not_ suffer from what is described in this bug. It played just happily for hours.

Hello Lars

Thanks for this info and for spending time to help us out.

When you switched from one cipher to the other did your router need to reboot?

Also did you test what happens if you switch back to AES? Does the issue come back?

I know you only want to listen to music without interruption so I fully understand if you don't want to do this test just now.

Thanks again
Felix

(In reply to comment #82)
> Hello Lars
> 
> Thanks for this info and for spending time to help us out.
> 
> When you switched from one cipher to the other did your router need to reboot?
> 
> Also did you test what happens if you switch back to AES? Does the issue come
> back?
> 
> I know you only want to listen to music without interruption so I fully
> understand if you don't want to do this test just now.
> 
> Thanks again
> Felix


Hi,

good to see such activity on bugs.

As noted in my first comment I really can't pinpoint to AES explicitly, but there is something going on, that causes it to loose connection. And in my testing it couldn't hang on to connections with AES.

Here are more details :

Router is a DLink DIR-655

Running mixed n/g/b 2.4GHz.

Auto WPA/WPA2 personal TKIP security.

Listening to "DR P3". At work now, will post instructions on setting the exact input tonight.

I will of course try to reproduce deterministically when I get home from work. Please bear with me, as I'm moving to a new house this week, there might be periods where I'm not responding quickly.

I'm a computer pro, and although I'm working with J2EE/integration etc, I know my way around most techs. So if there is something you can hint me to in the way of debugging and extracting logs etc, please feel free.

/Lars

(In reply to comment #83)
...
> 
> Listening to "DR P3"....

Denmark DR P3, WMA 128Kbps CBR

I haven't posted for a while because I did not want to jump the gun after installing the official release of 7.5.1 FW. I had great hopes the problem had been fixed, but no. My radio continues to drop what ever station I choose more or less 10 seconds after I turn it on. This happens whether or not I turn it on from standby with the power button and press play or from a preset. I have notice it on Vermont Public Radio, C-SPAN Radio, and C-SPAN 3.

What is even worse, something has happened to my alarm. Before the firmware up-date, the alarm (set for Vermont Public Radio) would go on for a second or two, then VPR would be dropped and the back up alarm would kick in. It was not very satisfactory, but at least it woke me up. Since the firmware up-date, I believe the alarm goes off because when I finally wake up, hours after I should have, and turn the radio on from standby using the power button, the station waiting to be played is VPR, not the station that was on when I went to bed, Pandora.

My theory is that before the sound ramps up to full volume the station is dropped before it is loud enough. The big problem is that the back up alarm does not seem to kick in any more, so there is no sound to wake me up.

I have been too busy to listen to the radio for any length of time so I can't comment on whether the radio drops stations later, but it very frequently drops them on first starting up.

My experience with drop-outs is the same as mpower's: it almost always stops playing within 10 seconds, regardless of the audio source. I have seen this with radio stations, Rhapsody, Mediafly podcasts, and even line-in playing with an mp3 device.

My alarm experience is a little better: it's true, the back-up alarm is gone, haven't heard it once since the upgrade. However, my chosen alarm stream (CT NPR) does fire reliably, although sometimes only for a minute before turning itself off. Sometimes it plays for a full hour.

(In reply to comment #86)
> My experience with drop-outs is the same as mpower's: it almost always stops
> playing within 10 seconds, regardless of the audio source. I have seen this
> with radio stations, Rhapsody, Mediafly podcasts, and even line-in playing with
> an mp3 device.
> My alarm experience is a little better: it's true, the back-up alarm is gone,
> haven't heard it once since the upgrade. However, my chosen alarm stream (CT
> NPR) does fire reliably, although sometimes only for a minute before turning
> itself off. Sometimes it plays for a full hour.

my experience(In reply to comment #86)
> My experience with drop-outs is the same as mpower's: it almost always stops
> playing within 10 seconds, regardless of the audio source. I have seen this
> with radio stations, Rhapsody, Mediafly podcasts, and even line-in playing with
> an mp3 device.
> My alarm experience is a little better: it's true, the back-up alarm is gone,
> haven't heard it once since the upgrade. However, my chosen alarm stream (CT
> NPR) does fire reliably, although sometimes only for a minute before turning
> itself off. Sometimes it plays for a full hour.

My experience is the same. After complaints to Logitech Tech Support, they told me that they now think it is a hardware issue and recommended that I send them the radio back so they could replace it.  I have sent mine back. But I don't really think it is a hardware issue.

To add to previous reports: also for my SB radio, the random drops improved somewhat with firmware 7.5.1 but didn't go away - with 7.5.0 they seemed to happen regularly within minutes of (soft) power on; with 7.5.1 more randomly but typically ~1/hour.

I reverted to 7.4.2 by installing the Windows SB server on my PC and the drops appear to have stopped (though the screen still freezes, apparently randomly, e.g. keeps displaying a podcast listened to yesterday even though live radio is now playing).

This observation suggests to me that the bug was not (or not exclusively) caused by changes at mysqueezebox.com but (also) by problems with the firmware.

After numerous complaints to customer support and no relief from the 7.5.1 upgrade, I was told that Logitech was now replacing radios as they believe that the streaming issue (and others that I have) are caused by a hardware issue. They mentioned "overheating" They asked me to send my radio in for replacement. New radio arrived yesterday. The hardware version is "5". This is the same hardware version as the previous one. I set up the new radio. It downloaded firmware 7.5.1.  I turned the radio on using a preset. The streaming stopped within 10 seconds. Same exact problem as I had before. 

Waste of my time. But at least we know it is not a hardware issue. (But we all knew that before).

Is there any word on when these bugs will actually be fixed?

Do they actually test these firmware releases before they are released?

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.

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.

I don't know why this has happened, but I wanted to report it.

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.

This bug is now open for a long time and affecting every radio.
I'm just surprised that nobody from Logitech has followed on nor commented your recent analysis.
Should all ask for radio replacement every week, or even for reimbursement ?
Should start posting negative comments on commercial web sites ?

Remark: I had the same replacement suggested by Logitech indian support team in April, which I declined as I knew it was not related to the problem.

(In reply to comment #92)
> 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.

I have found that this happens from time to time. I had a brief spate of undropped listening right after the FW upgrade to 7.5.1 and thought that the problem had indeed been taken care of. But then it came back with a vengeance.

Today, however, the alarm went off this morning and played properly with no problems. I turned the Radio on later and it played just fine with no drops. It was a good Radio day! Unfortunately, although you get a good day from time to time, a permanent cure does not yet seem to have been found.

Please see bug 16295 for a probable explanation for the stops-after-15 seconds and On-Off flipping problem, and a temporary workaround (comment #19).

(In reply to comment #95)
> Please see bug 16295 for a probable explanation for the stops-after-15 seconds
> and On-Off flipping problem, and a temporary workaround (comment #19).

Alan - Thanks so much. Very helpful. It is a pleasure to see that some progress is being made with this set of bugs.

Putting back accidentally-deleted CC users.

Since changes for this bug are now in the 7.5.x and 7.6 branches, I'm going to go ahead and mark this one as "fixed".  If you're not already, you can check it out by downloading a beta at http://downloads.slimdevices.com/nightly/

We're currently testing the 7.5.x *firmware only* for release to end users, which will include this fix (but will not include a new server software release).  When the release to end users occurs, I will move this bug to 'closed'.

If you experience new, similar problems in the beta or after the release, please open a *new* bug to track them.  This bug has gotten too complicated to work with easily.

In the initial bug description, you can link back to this bug simply by typing 'bug 16170' and bugzilla will automatically create a link.

Thanks!

(In reply to comment #98)
> Since changes for this bug are now in the 7.5.x and 7.6 branches, I'm going to
> go ahead and mark this one as "fixed".  If you're not already, you can check it
> out by downloading a beta at http://downloads.slimdevices.com/nightly/
> 
> We're currently testing the 7.5.x *firmware only* for release to end users,
> which will include this fix (but will not include a new server software
> release).  When the release to end users occurs, I will move this bug to
> 'closed'.
> 
> If you experience new, similar problems in the beta or after the release,
> please open a *new* bug to track them.  This bug has gotten too complicated to
> work with easily.
> 
> In the initial bug description, you can link back to this bug simply by typing
> 'bug 16170' and bugzilla will automatically create a link.
> 
> Thanks!

I'm still regularly experiencing this issue on two SB Radios connected to mysqueezebox.com. I'm confused---it sounds like you've got a fix in the beta versions of the SB server software... but what about us that use mysqueezebox instead? (Is this what you meant by the *firmware only* release?) Can you give me the exact firmware version that includes the fix and estimated release time? I'm using the latest firmware 7.5.? and still experiencing this almost every time I turn the radios on. And the fact that the alarm sounds also frequently cut off when they start to play makes this very unreliable as an alarm clock.