Buffering problem

[dj001]

I am having buffering problems despite the fact that testmy.net shows plenty of upload capacity.

I have four broadcasts, two shoutcast and two live365 live feeds. I have a standard business DSL account, which offers up to 80kB/s upload capacity when all broadcasts are disabled. For a year, I have managed this by setting the 96kbps shoutcast broadcast to MaxUser:7 and the 24kbps shoutcast broadcast to MaxUser:5. This way, when the DSL provider is being stingy and I have a full 7 96kbps listeners and a full 5 24kbps listeners, my upload capacity will never drop below 20 kB/s. (I noticed in the past buffering trouble only when it dropped below 10 kB/s.)

Yesterday, with upload capacity still showing a robust 35 kB/s and less than a full set of listeners, I started getting buffering trouble on the 96kbps shoutcast broadcast as well as on the 64kbps live365 live feed. Eventually, I got a "not streaming fast enough" error message and live365 disconnected everything.

So, I had to cut back both shoutcast streams to MaxUser:2, but I still get a few sound cut-outs here and there. What I don't understand is how, beginning yesterday, I started getting buffering problems, even when plenty of upload capacity remained in testmy.net.

Any ideas?

[dotme]

Could be packet loss between your location and Live365 - there are a lot of variables at play. Download pingplotter and run some tests. Sometimes, these things happen but go away on their own. About the only other thing I could suggest is outsourcing your DNAS hosting and that would make sure that all bandwidth is reserved for sourcing, and none used by listeners...

[dj001]

Then seeing 35-40 kB/s upload capacity in testmy.net does not ensure protection against buffering problems? Both the live365 64kbps and the shoutcast 96kbps streams had trouble.

[dotme]

Well, you would think it would be fine... but running pingplotter for 30 minutes would most likely expose any hop that experiences occasional packet loss. The only othet thing I could think of would be a CPU overload on the machine doing the encoding - unlikely, but possible I suppose. I assume there's no buffering when you connect to your SHOUTcast server locally?