View Full Version : Playback hangs on some longer songs (WMA)

2006-02-10, 21:32

to save diskspace and tidy things up, i have in the last few days, downconverted a whole bunch of ripped CDs from their original WMA Lossless to WMA VBR Quality 98. Conversion was batch processed through dbPowerAmp.

when i try to playback (brand new SqueezeBox3, fw=v29, srvr=6.22) any downconverted song that happen to be a bit long , will freeze at around the 6minute mark. the exact point of the freeze will vary from song to song, but the hang-point is 100% consistent within a given song.

CDs ripped natively at WMA VBR98, will playback flawlessly.
MP3s converted to WMA VBR in the same conversion app, have no problem.

it is only the files that were once Lossless and have been converted that stall. the display still says Playing, the Elapsed Time is static, and no sound is heard. it is not a hardfreeze, if you press pause, the display status will change to Paused, pressing Pause again will stay stuck at the same point. the remote lets you navigate as usual, and you can scroll down and play the next song, although if that song is long-ish, it will hang around 6minutes.
the behaviour is 100% repeatable, any converted file of sufficient length with stall.

no matter how long you leave it in the stalled state, it does not resume.
i have tried both wireless and hard-wired network connections. no difference.

my natural assumption would be some error during conversion which only shows up in longer songs, but it has to be said that the files will playback OK in Windows Media Player (which is usually a bit nervous about broken media files), also no problem in BSPlayer or VLCPlayer.

the smart money is still on some kind of conversion error ... but with all the other means of playback managing OK, i'm wondering if there is something slightly unusual in the converted files, some weird value in their file-header which although legal, is causing the SqueezeBox server some problems.

it's weird that it just sits there,not a hard crash or lock-up, but something is definitely confusing it.

first question, i s'pose, has anyone seen anything like this before?
apart from that, any suggestions gratefully received.
if necessary, if someone in tech wanted a look and poke about one of the sticky WMA files, i can probably upload it, or email it.
(the thought of re-ripping a few big boxes converted CDs as VBR98 natively doesn't exactly thrill me :0 - but i can hold on for now if we want to try and figure out what's happening)

sorry for the length of post, but wanted to get as many specifics covered from the get go, cheers

thanks - david

2006-02-14, 14:58
had a spare afternoon/evening ... so have done some testing and want to bump this topic up a bit.
results from my WMA VBR98 stall testing :


hey there's tables and conclusions and everything so rather than try to make it work in a msgboard, post as html file.

i know there's a bug track procedure, but justed wondered if someone at Slim could check what i say in the link to see if it makes sense and if it's worth raising a bug-report on it.

all the best,


2006-02-14, 17:26
IMHO it's always worth raising a bug report unless it's a dupe. It's easy to close it if not needed, and it saves losing the impressive amount of research you've done! One note - they'll probably want some test files so be prepared to make them available.

2006-02-15, 16:38
I've seen this same problem on files converted using Microsoft's own Windows Audio Converter. In my particular case I was converting to WMA VBR files at best quality.

2006-02-17, 17:31
thanks shawkie,

it's good to hear that it happens elsewhere, and takes the spotlight off the dbPowerAmp conversion and maybe back to the WMA built in code when dealing with high bitrate VBR files (not generated by Media Player).

with that confirmation, i'll see about sticking in a bug report.

like i say, the workaround for now is to uncheck WMA (built in) on the server settings.



2006-02-18, 02:16
I think this is probably covered by bug #2938.

For what its worth, I've had trouble with the server-side decoding chopping a fraction of a second off the end of WMA VBR files (only noticeable on dance mixes, live recordings, etc.) so your work around may not be 100% perfect either.