View Full Version : Dropouts on streaming audio

2006-05-19, 06:08
In the last few days started getting severe dropouts on streaming mp3 stations, such as the Shoutcast ones. This maybe related to my isp as recently my adsl has recently been upgraded. The symptoms are audio dropouts and breakups on these stations which occur is the data rate is more than 64Kbps. This happens both if I connect my Squeezebox to my local pc and to the Squeeze network. Lower rate streams play back ok, as do local mp3 files.

These dropouts don't happen however if I connect using mplayer/real player etc directly to the Shoutcast server, which makes me think this is not an isp issue. If I connect to my pc's slimserver using these players, I get dropouts and I see the player is buffering most of the time when playing these streams. This matches what I see on Server Health when playing these which indicates a low buffer fill status.

Any ideas? The server is an up to date 64-bit FC5 machine (AMD64). I've tried Slimserver 6.2.2 and 6.3 (20060518).

2006-05-19, 09:16
This happens to me from time to time as well.

Do you use a router? I often find that by rebooting routers, (unplug em)etc the issue goes away. Also, update the firmware.

Im not an expert but somehow resetting the IP stack with netsh command works too. This might be a placebo though.

Lastly, it doesnt sound like you are resource constrained but maybe something is running in the background that has higher priority than SS?

Hope this helps. Its really frustrating I know.

2006-05-19, 11:59
I do use a router/firewall but I don't that's the problem as rebooting doesn't help and streams work fine when played directly through mplayer. I doubt it's a resource issue either as dropouts appear with Squeeze Network which obviously doesn't go through my pc.

It makes no sense to me - can't be a problem on my SB3 since it's reproducible by connecting to http://localhost:9000/stream.mp3 in mplayer, can't be my pc/slimserver since it's reproducible using Squeeze Network, can't be my isp since when mplayer plays the stream directly it works fine.

2006-05-20, 04:21
Some further info - it appears that my isp has introduced some evil traffic shaping which looks like being the root cause of the problem. By turning on debugging on Slimserver when I get dropouts the interval between successive occurrences of

2006-05-20 12:08:53.3789 metadata size: 0

increases from the usual couple of seconds to over 10 seconds.

mplayer still plays with no dropouts, so I wonder if Slimserver is failing to cache/buffer the stream metadata for long enough and so interrupting playback if it fails to get these data frequently enough.