Bugzilla – Bug 4418
Ogg Vorbis streams crash player
Last modified: 2011-11-19 14:41:11 UTC
Trying to play Ogg Vorbis streams crashes the decoder in the player. Examples: http://8268.str.ovh.net:8268/graffic.ogg http://ebmradio.de:13000/ebm.ogg Once got an error stating "Ran out of memory for decoder". Other times the music just devolved to static and the graphic EQ froze.
I was easily able to reproduce this problem with the graffic stream Dan listed. It can happen anywhere from 10 seconds in to 1min 30sec for the player to begin producing static on my system. Richard, if we uncheck the Ogg 'built in' option on the file types pages, does that force transcoding of Ogg radio stations? If so that might be a workaround.
Yes, unchecking Ogg should mean the stream is transcoded and can be used as a work around.
*** Bug 4684 has been marked as a duplicate of this bug. ***
Same crash behavior on this stream: http://www.sofaspace.ch/stream.ogg.m3u. Specifics are "Ran out of decode memory" after a few minutes followed by system freeze (Dup. bug #4684); need to cycle power to reset firmware. Environment is SB3 firmware 72 logged on to the SqueezeNetwork decoding internet radio natively (no PC). (Perhaps update the 'Version' of this bug from 67 to 72?) Work-around is easy since the site offers an MP3 stream at http://www.sofaspace.ch/stream.mp3.m3u.
Also happens with the very latest fw81 from the nightlies. I didn't get an error message or even a lockup. Playback stopped after 00:01:20 of playback. The player still responded, but wouldn't play any sound (of any format) until after I rebooted it.
I experience the same thing with 6.5.2 on my Ubuntu server. I tried streaming Ogg Vorbis from my own icecast/OddcastV3 DSP server. It plays the first song without problems, but just as it starts on the next song, the decoder in the player crashes and has to be rebooted.
I can confirm this. I get the same error on a Squeezebox 3 using SlimServer 6.5.2 when playing http://eldoradio.de/broadcast/ogg.pls The SB shows a "ran out of decoder memory error" and freezes.
The problem persists with the latest SlimServer 7 nightly build (09/09/2007).
same problem here with SB3 and Firmware 81. Slimserver 6.5.4 on opensuse 10.2 Perl v5.8.8
I'm having a similar problem with an SB2, see http://forums.slimdevices.com/showthread.php?p=251258. I'm using SqueezeNetwork, so I don't have the option to workaround the Ogg stream. I get the message "invalid decoder" before the unit goes into Zombie state. I'm trying to play http://stream2.krcl.org/krcl-high The annoying thing is that this was working a few days ago - maybe something has changed on the SN side?
We'll need to look at this again, post 7.0.
i have just recently seen this bug while playing vorbis from my slimserver's hard drive, which could indicate that it not just a problem of those specific streams. please refer to my last post in thread: http://forums.slimdevices.com/showthread.php?p=269222 i am starting to think there may be a memory leak (if such a thing is possible in SB) in the vorbis decoder, which is more or less aggravated depending on bitrate, stream format, encoder used, etc.
I've also run into this bug, but I know what's causing it... it's the metadata update from the server. If I turn the updates off, the stream plays fine. If I force an update, the stream immediately halts with the same symptoms everyone's said already. This is why people are seeing at the transition between songs... that's typically when the update is sent.
Hi, I experienced the same freezes witj my Transporter. This happens when listenting to the sofaspace webradio from both SqueezeNetwork and SqueezeCenter. The radio streams in OGG format and sends the metadata. At the end of each song, the Transporter severely freezes and needs the power cable to be unplugged. After some searches on the web, it seems effectively that the tag formatting may be problematic. Firstly, no metadata are displayed by the Transporter (Winamp displays them correctly). Secondly the problem appears systematically at the end of each song, when a new tag is transmitted. I read on the website of sofaspace (www.sofaspace.ch) that other users experienced some stream drops caused by the metadata transmission (with soft music players).
Bug #5167 seems to be a duplicate of this bug. In addition to the comment I made to #5167: I tested Firmware 86 with Squeezecenter 7.0 (squeezebox v3) and I still cannot play ogg internet radio streams - I get still the infamous 'decoder out of pram' message and the box hangs (need to soft-reset it via 5-sec-press-rc-power-switch). For current test urls of ogg-streams see the comments of #5167.
*** Bug 5167 has been marked as a duplicate of this bug. ***
This bug is now open for 18 months. The advertised feature 'native ogg playback' is _the_ reason, why I bought a SqueezeBox. Is there is some schedule, when this bug get fixed?
Felix and Dean, was there a reason this was targeted to 'Future'? If not, I have set it to a target of 7.1.
My info: ===== SqueezeCenter Information SqueezeCenter Version: 7.1 - TRUNK @ UNKNOWN - Debian - EN - utf8 Server IP address: 192.168.1.2 Perl Version: 5.8.8 i486-linux-gnu-thread-multi MySQL Version: 5.0.21-standard Platform Architecture: i686-linux Hostname: debian Server Port Number: 9000 Total Players Recognized: 1 Player Information Name: Yuval Drori Model: Squeezebox v3 Firmware: 88 The IP address for this player is: 192.168.1.5:47717 The ethernet MAC address for this player is: 00:04:20:12:0f:d8 Wireless Signal Strength: 71 Initially I had all my library in ogg format but with empty tags and had no problems. Last week I used easytag to add metadata to ogg files including embedded album art - since then I have tried all flavors of the server including todays 7.3 trunk from svn but when trying to play I get the decoder memory problem or the bad display problem.
There are other product (from Creative and other brands) witch are cheaper than the squeezebox but they can't play ogg vorbis streams, while the squeezebox SHOULD be able to play them as stated on the box and on the slim devices web pages. This was the reason I bought the squeezebox. But attempting to listen to ogg vorbis internet radios (http://www.thedividingline.com/listen-high.pls is an example) crashes the box as described in this bugreport. This bug is known since 18 MONTHS, my question : WHEN CAN WE EXPECT TO HAVE THE SQUEEZEBOX WORKING AS ADVERTISED ?????? Or may we start a class action against Logitech ?
When this is fixed, also retry bug 7857
*** Bug 7604 has been marked as a duplicate of this bug. ***
http://relay0.fm4.amd.co.at:31337/fm4-hq.ogg is another stream that does not work on the Squeezebox.
Ogg Vorbis AIFF Disabled sox FLAC Enabled sox/flac <- MP3 Disabled sox/lame Ogg Vorbis Disabled Native This setup doesn't crash sb, but sound is interrupted. Other settings: no sound Native: Ran out of Decoder PRAM, recycle needed These settings cannot be modified in SqueezeNet, it always Runs out of Decoder PRAM (regardless of buffering time). Squeezecenter 7.0 (squeezebox v3) Thanks for your attention - this is a critical bug
My 2 cents... I just ran into this 22 MONTHS OLD bug a couple of days ago too. The issue as already described in previous posts: For a particular Ogg Vorbis track, "Ran out of decode memory" occurs on display, followed by system freeze; to regain control a power cycle is needed. I first assumed that I had encoded the track with too high a bitrate, that is, until I found this bug report. Then it hit me that I had added a cover picture to the Ogg Vorbis metadata, Its a JPEG, about 32 KB, meaning that in total the metadata size is somewhat above 32768 bytes. Here's the intersting bit: removing the picture, or putting in a smaller one, lets the SqueezeBox play the track, without any errors. My guess is that there is some internal limit to the metadata size, and/or a buffer overflow in the firmware.
The bug you want is bug 7857.
Dan Evans tells me more customers are complaining about this issue. Sean, should this still be assigned to you, or is it something Felix could work on?
I'll take a look too.
http://engine.collegemedia.vt.edu:8000/wuvt.ogg The above Ogg Vorbis stream crashes my Squeezebox Duet player. This is the excellent ausio stream for WUVT 90.7 in Blacksbug, VA USA Please fix this bug!!!!
http://engine.collegemedia.vt.edu:8000/wuvt.ogg The above Ogg Vorbis stream crashes my Squeezebox Duet player. This is the excellent audio stream for WUVT 90.7 in Blacksbug, VA USA Please fix this bug!!!!
http://engine.collegemedia.vt.edu:8000/wuvt.ogg doesn't crash the player, but it doesn't play due to a header parsing issue.
...due to a header parsing issue. does it apply for http://fm4.nobody.at:8080/fm4-hq.ogg as well?
A customer wanted me to post this on his behalf and to let our developers know that this should be a high priority bug. Customer's comments: I request that the identified software bug be fixed as a high priority. The software bug is identified as Bug 4418 The problem is that the Logitech Duet will NOT play the common and popular ogg streams. The main reason for my purchase of the Logitech product was to play ogg streams and THIS OGG STREAM CAPABILITY IS ADVERTISED IN THE LOGITECH DUET LITERATURE AS A COMPATIBLE AND SUPPORTED STREAM FORMAT. What can I do to get the software bug 4418 fixed at a higher priority level? This ogg stream software bug 4418 has been known and reported for a very long time. Please let me know how to get Logitech to make this a high priority issue.
More than one year since last time I had a problem with this issue: http://forums.slimdevices.com/archive/index.php/t-35821.html ..but now I can't find the "Unchecking built in ogg in server settings/file types" in SqueezeCenter any more. This bug renders my complete music collection totally useless on my slim player after upgrading to squeeze center 7.2 (on ubuntu). I am not able to understand the "settings"-"advanced"-"file types"-UI, but have been playing around with the ogg-ogg-native/disabled without anything but silence from the player (hard resets pulling the power cord from the player between tries). My problem could just as easily be bug 7857, but "ran out of decoder data memory" is the symptom.
Same bug here, the player freezes after 1 minute while playing an ogg stream. However, if I set my alarm to wake me with an ogg stream, it plays just fine (for an hour, until the alarm times out). The difference is that no station info is displayed while playing the stream as an alarm. ( test stream: http://trio.icecast.linxtelecom.com:8000/uuno.ogg )
Per other comments, adding a folder.jpg file (126kb) to an ogg-vorbis file caused the system to lock up. On Transporter the screen did a 'white out'. Resolved by unplugging the Transporter power & restarting. Removing the jpg from the ogg file allowed it to be played normally. Dan
http://relay0.fm4.amd.co.at:31337/fm4-hq.ogg still does not play at 7.2.1 on the squeezebox. The ability to play ogg being a main reason for buying this logitech product, I am getting frustrated and have stopped recommending it to friends. no last fm, no pandora is another detracting factor. WHEN can we expect ogg streams to work flawlessly?
http://relay.radio.ethz.ch:8000/sender.ogg crashes SB and BB SZ: 7.2.1 SSODS: 3.15
alright, bug's been open for over two years (!) now. is milestone 7.3 sill attainable? ;-) could this also be causing FFW/REW to break on vorbis files with embedded artwork? (this is what i am seeing). i posted some details here: http://forums.slimdevices.com/showthread.php?t=54902
No, not going to happen for 7.3.
This bug has been opened 2006-10-23 Today we are 2008-11-14 My question : how long will you people at Logitech still take our customers for idiots ans dell a product that can't do what it is advertised for ?? What would you say if you had a car with the motor stopping 3 times a day while you're driving, and the problem hasn't be fixed in more then two years ? You are lying in your advertisements that your products can play ogg vorbis, and you are unable to fix that in more than two years... What a shame... I regret my purchase, the only positive thing is that somme people didn't make that same error as me, because I warned them before they buy your defective products. NEVER LOGITECH AGAIN
(In reply to comment #40) > No, not going to happen for 7.3. > Andy, are you guys using Tremor or libvorbis? As per your comment here: https://bugs-archive.lyrion.org/show_bug.cgi?id=7857#c10 the "vorbis API" needs an overhaul, not a 'dirty hack'. So we've established that it's a memory issue, that it's a bug that has been open for over 24 months, is caused by an upstream API, and that you've got a lot of angry customers because of it. I agree that a 'dirty hack' is not the correct approach. That doesn't mean the slimdevices/Logitech has to sit around and lose customers while the bug is "properly" squashed upstream. A) I'd love to know a little more about how/where the bug is causing the receiver to fail. IE: has it been narrowed down to a specific API call? Vorbis is a big open source effort, and there should certainly be a bug report open upstream with testers/developers working on it. B) You could _at least_ handle this in squeezecenter; it seems like you rescale/resample the cover art and send it apart from the actual ogg file. If that is the case, why not use SqueezeCenter (which is already reading these headers) to detect a coverart (or comment, whatever) header field that is going to crash the API on the receiver and stream an OGG file with the offending header truncated. It will allow all these irritated users to play their ogg files until Xiph developers can fix the API. 24 months is an unbelievably long time to have a critical bug open on a format you support.
This bug is not related to bug 7857. Please post your comments in the appropriate bug so people don't get confused.
(In reply to comment #43) > This bug is not related to bug 7857. Please post your comments in the > appropriate bug so people don't get confused. > Are you certain that users reporting this bug aren't being affected by the stream metadata being updated with headers that trigger bug 7857? Regardless, would you prefer I repost my previous comment in bug 7857 or simply take the discussion there?
Yes... This bug is related to the fact that these radio streams use multiple Vorbis streams concatenated together inside a single Ogg container and our implementation does not properly handle this situation.
Changing target to next release
Oh my god, you did it again. This is like the 20th time you changed the target milestone and nothing else happened. I mean WTF?!? > 2 years time to fix this ... And if your firmware code is such a nightmare to change, just disable the metadata parsing code completety for ogg streams as a first step to fix this.
James, Andy, et al Seriously, what. the. fudge. over? Defer, defer, defer, defer. Can't you guys just stop-gap fix this and then do something meaningful and "proper" later on? This is ridiculous. You can play OGG files but you can't play OGG streams, which is half the f-ing point of having a Squeezebox in the first place. So, as OGG/Vorbis/etc. garners more widespread adoption as a streaming format, there's more and more content the Squeezebox/Squeezecenter can't play. With the aotuv enhancements, OGG/Vorbis is the *best* sounding format at extremely low bitrates, which makes it more and more attractive to content providers. So, stop f-ing around and take maybe one man week of effort off of prettying up Squeezecenter and track this down and fix it. What might be a bunch of angry customers rumbling in a (semi-)private forum today may very well be a very public embarrassment for Logitech if it goes viral.
Your comments are not helpful. If you don't have something to contribute, please don't post in this bug.
(In reply to comment #49) > Your comments are not helpful. If you don't have something to contribute, > please don't post in this bug. Who is your supervisor and how do I reach them? I'm sorry if you feel our comments are not helpful, but you're certainly not being very helpful to us, either.
Hi. I'm Andy's boss. You can reach me at the address here. I apologize for the delay in fixing this particular bug. It's a really hard one to fix and we understand that it's important to a number of customers. Unfortunately, the hardware memory limitations on the device mean that we have to do a LOT of special tricks to make Ogg work at all, and when we initially shipped Ogg support it worked well, but the streams have changed over time and we lost some compatibility. Please understand that we take this seriously and are as frustrated as you are about time and difficulty involved fixing it.
For Andy Grundman : The 2 comments prior to yours maybe not be helpfull but they are relevant that people are pissed of waiting for a solution for more than 2 years. And they have been a lot of helpfull posts for this bug. Unfortunately I don't live in the USA, I would start a class action against Logitech-Slimdevice. An ANGRY customer. Roland
When can we expect 7.3.2 to be released? Another week w/o the purchased feature.
We need to retarget this bug again. This is a very difficult bug to fix and we may go with an option to fail gracefully when playing a stream that would otherwise crash the player. Please don't post to this bug unless you have something constructive to add.
It would be very CONSTRUCTIVE if I could get my money back.
(In reply to comment #54) > We need to retarget this bug again. This is a very difficult bug to fix and we > may go with an option to fail gracefully when playing a stream that would > otherwise crash the player. > > Please don't post to this bug unless you have something constructive to add. > Andy, I'm still (slowing) hashing away at my patch in my free time. I'll work on cleaning up and opening up what I've done in case it spurs idea from other people that can piggyback on and maybe run with the torch while I do microprocessor design classes.
Encountering: "ran out of decoder data memory" message with player lockup when playing this ogg stream. I have read the comments and understand this issue is being worked. Am not having problems with playing ogg encoded music local, only streams. Haven't noticed this problem until recently... probably due to the fact that there weren't that many ogg streams a few years ago... recently they seem to be getting more popular. This stream hangs reliably: http://www.jazzradio.hu/jazzradio_ogg_128.m3u
Wanted to give you guys an update... I've been working on this bug and have made some progress. It appears 64k and higher Ogg streams are working fine. There is still more to do, though: * Support metadata (comments) by sending them to the server. This requires fixing bug 7857, but I have made some progress on that bug too. * Low-bitrate streams (<64k) require more memory for decoding and don't work right now. I need to see if it's possible to support these.
Current status: Work is done, most streams play now. Low-bitrate streams and files unfortunately cannot be supported due to memory limitations, but they will fail gracefully. Look for an updated firmware in 7.3.3 within a week or so, pending QA.
New firmware is now checked in, please test!
Wow, thanks for putting this higher on the agenda, guys! I'm not an expert, but is it possible for squeezecenter to somehow transcode the lower bitrate streams into 64k+ (or even outright raw WAV) to avoid the memory constraints in the squeezebox?
After the update playing http://radio.uni-bielefeld.de/stream/hertz-q5.m3u put the box into a funny state (inside the .m3u it is http://radio.uni-bielefeld.de/stream/hertz-q5.ogg). I.e.: 1. it plays this stream fine until the current song is finished 2. then the display freezes 3. the box stays responsive to the remote - one can navigate through the menu etc. 4. playing other streams does not work anymore until the next reboot Just tested the firmware update (box displays firmware version 121). About 1): this radio-station sends between songs new track information
Sorry I should have said this will be in tonight's nightly build. Firmware versions: SB2/3 124 TP 74 SBR 59 Boom 44
as for now 7.3.3-24758 and 7.4-24756 install 123 on SB. Boom Ran out of decoder PRAM,SB stopped and just would not play anything after the ogg HQ Stream. 1. Please inform us when the correct and tested Version is online for download - not when it might be. Why update the Changelog with stuff that is not fixed? 2. What is failing gracefully? 3. what is low and high quality (Bitrate please) Thanks : )
http://downloads.slimdevices.com/nightly/latest/7.3/ Low bitrate is anything with quality less than 0 (-1 or -2). Quality 0 is 64kbps, so anything 0 or higher will play fine. Failing gracefully means the stream will fail with an appropriate error message instead of crashing.
Question for Andy--can you elaborate on the memory limitation for <64K streams? I'm concerned that because Ogg is VBR that some tracks encoded at higher bitrates may still dip below 64K during periods of silence.
No, the limitation is based on the quality the file/stream is encoded at, not the bitrate. Quality less than 0 won't work.
squeezecenter-7.4-24777 plays my favorite 160kbps stream flawlessly. how can we reward you? Thank you so much, after all this time, you made the product work as intended. : )
Sounds like the ogg stream bug may be fixed. How do I get the new Squeezebox Receiver firmware 59 installed? Receiver currently sits at firmware 58 and controller indicates "the software is up to date. version 7.3 r3476 ?? Please advise. Thanks!
See previous comment with the nightly download link...
FYI: I've been running Rev. 24920 of 7.3/trunk for a while on my SB3 (FW 124). I'm no longer seeing the "Out of decoder memory" error. But some days ago I was playing an OGG Vorbis stream which after some time produced only noise before crashing the Squeezebox. The Squezeebox then rebooted itself and has been working fine since then, i. e. I haven't been able to reproduce the problem. The stream in question is http://eldoweb.eldoradio.de:8000/160.ogg
I've seen the same crash with noise exactly once too, out of many hours of playing Ogg streams. Going to be very hard to track that one down.
The same happened to me. The Squeezebox suddenly made loud fizzing noise. I had to pull the power plug. But since then all seems to work ok.
I had it twice, but blamed it on the alarm when it happened on boom. will try to send log if I find the day it happened. kkkkkkkkkkkkkkkkkkkkzzzzzzzzzzzzzzzzzzzzzzzzzzzz unplug
Unfortunately a log won't help. We need to find a way to reproduce the crash.
Verified fixed in SqueezeCenter 7.3.3 r26407 Tested all listed HTTP// strings in this bug. All worked fine, except the 404 File no found links :)
This bug has been fixed in the 7.3.3 release version of SqueezeCenter! If you haven't already. please download the new version from http://www.logitechsqueezebox.com/support/download-squeezecenter.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
*** Bug 12404 has been marked as a duplicate of this bug. ***
My SB3 player crashed twice in one day playing the 224kbps Ogg stream of D-dur. http://radio.cesnet.cz/cgi-bin/cro-d-dur-256-ogg.pls . As others have reported, a loud fizzing noise corresponding to random data being output to the DACs and a few seconds later the player reboots itself. This does seem associated with changes in metadata to indicate the currently playing track. Classical stations can often send out very long track identification strings, including composer, work, orchestra, conductor and soloist credits. One thing I noticed is that just prior to crashing the music changed but the metadata remained stuck on the display corresponding to the previous track. Example of the metadata changes (from mplayer output): Demuxer info Name changed to Cesky rozhlas D-dur (Robert Schumann: Raj a Peri op. 50. Oratorium pro solove hlasy, sbor a orchestr). How long would this string have to be before it could cause buffer overflow? Anyway, the bug is reproducible but may take several hours of play before it appears. Version: 7.3.4 - 27488 @ Sat Jul 18 03:01:58 PDT 2009 Hostname: shuttle Server IP Address: 192.168.1.60 Server HTTP Port Number: 9000 Operating system: Windows XP - EN - cp1252 Platform Architecture: 586 Perl Version: 5.8.8 - MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt Total Players Recognized: 3 Player Model: squeezebox3 Firmware: 127 With my regrets to Andy, but can we have this bug reopened, please?
It may be possible in-stream metadata could crash if it's really large, I will test this station and see.
I've not been able to reproduce this crash. This stream is not sending much metadata, just a single title element, so that's not going to cause any problems.
Just wanted to let everyone know that was interested in this bug. Squeezebox Radio and Squeezebox Touch (and SqueezePlay) can now play Ogg streams of any bitrate. So those low-bitrate stations such as CBC that take too much memory for the older players can now be played.
I have the same issue and I am able to reproduce it. By playing this file to a SB classic, the device crashes instantly with 'Ran out of decoder memory': http://www.tozz.nl/temp/sbcrash.flac (112 MB). This is a dolby surround FLAC file that happend to be in my playlist. I am aware that SB does not play dolby suround files, but it should not let the device crash either. This was tested with Logitech Media Server 7.7.0 r33614 @ Tue Oct 18 11:07:25 PDT 2011