Bugzilla – Bug 3969
beta ogg vorbis streams kill audio output
Last modified: 2008-12-18 11:38:58 UTC
I recently upgraded to the new 6.5 series, with firmware that can play Ogg Vorbis streams. Most of my music is in Vorbis encoding, and some of it was encoded before the specification was finalised. It seems that when the squeezebox tries to play one of these, it dies in a peculiar way. It can't play them, but it doesn't skip over them either. The analog VU-meter (my usual screensaver) just freezes. I can escape to the menus and try to play other tracks, but no other tracks will play after this freeze. Also, the display does not refresh properly after this. I can see the new menu text, but the pixels which were illuminated for the VU-meter stay illuminated, and are not cleared to show the new text. I'm not 100% sure, but at this stage it seems to me that the freeze occurs if the vorbis file was encoded with a beta encoder. For example, one I have here has this info: toojays@fuzz:/home/music/singles/02$ file Noxious\ Emotion\ -\ Boundary\ \(Matrix\ Remix\).ogg Noxious Emotion - Boundary (Matrix Remix).ogg: Ogg data, Vorbis audio, stereo, 44100 Hz, ~128000 bps, created by: Xiphophorus libVorbis I (1.0 beta 4) I'm pretty sure that the older software/firmware combo (which converted Ogg Vorbis on the server) was able to play this kind of file without problems (can't be 100% sure since I don't have many of these beta files). Versions: Player Firmware Version: 59 Slimserver from deb, on Ubuntu 6.06 LTS, downloaded around 19/8/2006 (latest at time of writing).
Let me know if you need an example file. I tried to upload one to this bug, but it caused an internal error in bugzilla. :(
It sounds like you have a corrosive music file there, capable of killing any software it touches! :) Feel free to email me a file.
Created attachment 1450 [details] ogg file that kills slimserver audio
I can reproduce your symptoms exactly. Once I try to play this file, I cannot play any others. The progress bar just stays at 0. Note our goal for this file may not include trying to make it play correctly if it does turn out to be a very nonstandard file, although it's possible that may happen. The primary goal has to be not having the player firmware break like this!
Yep, that's understandable. I have so few of these files that it's not going to be a problem if I end up eliminating them from my collection.
The firmware won't be able to decode this track, it turns out the ogg codebooks have a very large memory requirement. I suspect this is due to the beta encoder being used, but cannot be 100% certain. Squeezebox2/3 fw 60, Transporter fw 9 will not crash when trying to play this track. When bug #2469 is implemented then these tracks will automatically playback using transcoding. The firmware is currently undergoing internal testing. You will be notified again when it is made part of a nightly release.
Created attachment 1479 [details] Another ogg file that crashes fw59 from the beta forum
I have been testing the ogg file from the beta forum, and this still crashes firmware 60. A stack overflow occurs after the codebooks have been loaded during playback. Another fix will be required for this second file.
Ditto. Firmware 60 still "crashes" on all my libvorbis 1.0 rc3 encoded files. By "crashes" I mean... 1) display always screwed up, 2) music plays but occasionally drops out or disintegrates into noise, 3) remote control sometimes unresponsive. I have about 200 CDs worth of oggs that fall into this category... 1.0 rc3 was the "stable" version of libvorbis for a very long time (two years? more?) before 1.0 was finally released, so I imagine I'm not alone in this. I'd also like to add that every ogg-capable portable player that I've tried (several, including a tiny flash-based iRiver) plays these 1.0 rc3 oggs fine.
I have improved the ogg vorbis decoder memory usage in firmware 62. This will now play the second attached ogg track ('Another ogg file that crashes fw59 from the beta forum'). It will not be possible to support the first attached track. The firmware is currently undergoing internal testing. You will be notified again when it is made part of a nightly release.
Good news for me... it seems at least some of my 1.0rc3 encoded files work fine now. Are there better memory allocation checks in firmware 62 to prevent the SB from "crashing" when a file that would cause problems is played? Is there a specific limit to the codebook size above which it's known not to work? I'd like to write a quick program to check my collection for trouble spots so I don't have to play every file to find which ones don't work.