Bug 5167 - Playing this OGG internet radio stream hangs Squeezebox
: Playing this OGG internet radio stream hangs Squeezebox
Status: RESOLVED DUPLICATE of bug 4418
Product: SB 2/3
Classification: Unclassified
Component: Audio
: 81
: PC Windows XP
: P2 normal (vote)
: Future
Assigned To: Felix Mueller
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-14 15:24 UTC by Andy Connors
Modified: 2008-03-27 17:50 UTC (History)
4 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Connors 2007-07-14 15:24:13 UTC
This one may be hard to duplicate, but for the past two days it's been 100% repeatable for me, as the streaming of the station itself appears to be faulty at the present time.

I've had intermittent problems with this internet radio stream in the past, but using 6.3.1 the result has simply been that the music plays for a few seconds, then stops.  No other ill effects occurred with 6.3.1.

Steps to duplicate:
1) In "Tune In URL" box, enter http://217.150.128.237:8000/jazzradio128.ogg
2) Music will play for a few seconds, then stop.
3) After doing this, the SB gets into a "zombie" state, where it seems to be working properly, responds to the remote and the SlimServer web UI fine, but no sound will play either with internet radio streaming or trying to play music from the library on disc.  Output is taken from TOSlink to an external DAC.
4) The only recourse I have found is unplugging the SB hardware to re-boot it.  Using the Power button to put the device into standby doesn't clear the error.

Notes:
I have my display settings as follows:
Brightness when on: 3
Brightness when off: 1
Brightness when idle: 2
Automatic display brightness: Adjust brightness automatically

When playing the stream, a few seconds before the music stops the SB display brightness suddenly goes to full (4) by itself.

Network connection is wireless G, using a Linksys WRT54G.  Using 6.3.1, there is a graceful recovery from the error.  Internet provider is Comcast cable.  Browser is Firefox 2.0.0.4.
Comment 1 Chris Owens 2007-07-16 10:09:11 UTC
This was as easy to repro for me as it was for Andy using the provided URL.  10/10 attempts resulted in an audio lockup within 60 seconds.

Richard, should I start assigning SB3 FW bugs to Martin or should they still go to you until he starts?

Also, if they should go to him, don't forget to assign any existing SB3 FW bugs that you have!
Comment 2 Chris Owens 2007-07-16 10:15:08 UTC
Reconnecting the power supply or simply rebooting by holding the power button fixed the problem.  

This just in!  With careful observation I noticed a message fly past at one point which said (I think) 'Out of decoder PRAM'!
Comment 3 Spies Steven 2007-07-16 11:06:18 UTC
Richard, I see the same issue on a Transporter running FW31.  I was able to catch "Ran out of decoder PRAM!" displayed on the screen just before it stopped playing.

Andy, instead of unplugging the unit when this happens you should be able to reboot by holding down the power button for about 5 seconds.  The unit should then reboot and then connect back to your network after a few seconds.  To get around this issue for now you can disable native ogg playback.  To do this in SlimServer navigate to 'Server Settings' then 'File Types' then remove the check mark from the line 'Ogg Vorbis Ogg Vorbis (built-in)' and click change.
Comment 4 Andy Connors 2007-07-16 11:33:42 UTC
Thanks for the tip about the reboot with remote.

Also, I was able to work around this problem this past weekend by disabling the built-in ogg decoder.  But when I did so, I bumped into the "socketwrapper hang on stop" bug described in bug report #5164.  See the notes there for details.  It takes both Bryan Alton's socketwrapper.exe fix from this past weekend (7/15/2007), and disabling the built-in ogg decoder to get this ogg stream to work correctly for me without hanging when the stop button is pressed.

The "sorketwrapper hang on stop" will be experienced by users if all of the following conditions are met:
1) Windows
2) Sox or AACplus streams where the associated built-in decoder is disabled
3) A single-core CPU with no hyperthreading

See bug #5164 for more details.
Comment 5 Spies Steven 2007-07-16 13:36:22 UTC
This bug is most likely a duplicate of bug #4418.

Here is another stream reported in the forums that exhibits the same behavior:
http://warszawa.radio.pionier.net.pl:8000/eska-warszawa.ogg

Comment 6 Pablo 2007-07-16 13:47:36 UTC
(In reply to comment #4)
> Thanks for the tip about the reboot with remote.
> 
> Also, I was able to work around this problem this past weekend by disabling the
> built-in ogg decoder.  But when I did so, I bumped into the "socketwrapper hang
> on stop" bug described in bug report #5164.  See the notes there for details. 
> It takes both Bryan Alton's socketwrapper.exe fix from this past weekend
> (7/15/2007), and disabling the built-in ogg decoder to get this ogg stream to
> work correctly for me without hanging when the stop button is pressed.
> 
> The "sorketwrapper hang on stop" will be experienced by users if all of the
> following conditions are met:
> 1) Windows
> 2) Sox or AACplus streams where the associated built-in decoder is disabled
> 3) A single-core CPU with no hyperthreading
> 
> See bug #5164 for more details.
> 
Hi I had the same problem with "http://www.radio.pionier.net.pl/stream.m3u?radio=eskawarszawa"
after disabling ogg decoder everything is ok. The only issue is that screensaver(Now playing jump back on wake) is choking no, but I can live with this. It is only slow motion when playing this station. Other stations screensaver is on same for wav
Comment 7 Spies Steven 2007-10-04 14:29:37 UTC
*** Bug 5665 has been marked as a duplicate of this bug. ***
Comment 8 Richard Titmuss 2008-01-10 12:34:13 UTC
Reassigning Squeezebox firmware bugs to Felix.
Comment 9 Georg Sauthoff 2008-03-17 03:27:14 UTC
I hit this bug with squeezebox, too. While

http://radio.uni-bielefeld.de/stream/hertz-q5.m3u

is streamed for a few minutes, the device shows the infamous 'decoder PRAM' message and waits for a reset.

I have the theory, that the time the device hangs after starting the ogg-playback, depends on how often the streaming-server inserts new-track-information (like if a new song starts). I.e. if you have a live session without tag changes, then you can listen longer to the stream  before the hang. But perhaps this has nothing to do with it.

Another stream, where I have the same problem is:
http://www.dradio.de/streaming/dlf_hq_ogg.m3u

The device shows, that it uses Firmware 81 - and I am currently playing these streams via SqueezeNetwork (over WPA-WLAN).
Comment 10 Chris Owens 2008-03-27 17:50:12 UTC

*** This bug has been marked as a duplicate of 4418 ***