Icecast Streaming Media Server

[stereotype]

The scenario:

A client that connects to my icecast2 server experiences constant disconnections.
A traceroute to his IP reveals a blottleneck in between north and south america.
I'm guessing that in practical terms, not much can be done about that.

So, the music still plays, but every 5 or 10 minutes the stream player stops, and it re-connects.
So, my question is:
What would be the best settings for icecast2 for such a scenario?
Playback latency is not really a concern...
My current settings are:

<queue-size>524288</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>245760</burst-size>

I guess we are mainly concerned with <queue-size> and <burst-size>, but is there anything else I should be looking at?

The client is a hardware player that buffers 20sec of stream by default, and that cannot be changed. The stream is lame abr mp3 at 80kbits/s.
I calculated 20 seconds of 80kbits/s to be 204800Kbytes, but not sure how that fits into the equation.

In such a scenario, should i turn off burst-size, make it 204800, or what?
Should I make the queue-size insanely big, like 8MB maybe?
Or, can I turn off queue-size at all?

How exactly does icecast triggers the queue size limit? Would the buffering of 204800 bytes count towards the queue size?

Also, does <client-timeout> does anything at all? All documentation say its not used at the moment, but most docs are rather old...

Any help would be greatly appreciatted...

Thanks

[karlH]

Firstly make sure you are running the most recent release.

With a 200k+ burst, that is at least around 20sec@80kbps. The question is what actually happens when the client disconnects. If it is down to the the client falling too far behind then you can have a large max queue size (8 meg is certainly allowable but 800 seconds is a long lag time). The 200-300k difference between burst and queue size is not vast, < 30 secs, so increasing the queue size is not unreasonable.

Having a larger burst will mean that the player has more data to process in case of stalls. Maybe this particular listener is just having a stall every so many seconds, with the stall being big enough to leave that at 500k lag. If the icecast->listener link is not able to sustain the 80kbps then that listener will always have issues at that bitrate.

If you don't want a huge burst for everyone then you can have one mountpoint with a short burst (eg 64k) and another which is a local relay of the first mountpoint with a larger burst and queue.

karl.

[stereotype]

Thanks for the quick reply Karl

I hadn't even noticed there was a new release out! That's very nice.
Every now and then I would check the website for a new release or some news but there was nothing ever there...
How does this new release compares to your KH releases?
I was just starting to investigate them...

But back to that subject...
I noticed that I was getting a lot of slow_listeners from that client...
Does that mean it is icecast that is kicking the listener out due to queue-size?
Or if the player runs out of juice/buffer and can't keep up, does that also cause an slow_listeners event? Or would icecast see that as a mere disconnection?

I'm experimenting with queue-size at 8MB now...
Can queue-size be turned off at all? Or could that have nasty effects?

[karlH]

slow listeners is the count of clients that icecast disconnected because they were <queue-size> bytes behind (~512k in your case). Without a queue then no burst or buffering could be achieved. So tolerances for listeners would be extreme tight.

The kh releases is a testing branch, wrt the queue, there's no difference but there are differences in other aspects, mainly internal and various settings. The NEWS doc describes the changes.

karl.

[stereotype]

Thanks Karl
The 8MB seems to have solved the problem
One question though:
Is the 8MB a global "buffer" or each and every "slow" client will create its own 8MB? Also, if I have two slow listeners on separate mounts/streams, will there be a buffer of 8MB for each?
We stream 20+ channels, so I'm just a little concerned about memory consumption.

[karlH]

I'm not saying 8meg is a magic figure, but if that works for you then fine.

The queue-size is a measure of the maximum amount icecast will allow the shared queue to expand to. All listeners on the same mountpoint refer to the same queue data so 10000 listeners could be slow but only 8 Meg is allocated to the queue.

The queue is tied to the mountpoint, so it's possible to have 8Meg for each of your 20 mountpoints. Your can of course define a different queue size for each, you may find something less is better eg 2Meg, also lower bitrates mean the queue will represent a longer period.

karl.

[stereotype]

Sure 8meg is not magic, it was picked almost randomly anyway
I just never set it so high cause I was affraid of some exponential side effects...
But if these 8meg can be share by 10,000 folks then I don't see why not...

Thanks again...

[stereotype]

Karl, another question on the same subject

The hardware players we use are quite persistent on reconnecting...
Even when you kick a listener out via "List clients / Action / Kick", the players reconnect within a mere second...

With that in mind, what exactly happens when a listener "fills up" <queue-size>, gets kicked out, but quickly reconnects?

Does it "re-join" at the end of the buffer, or does it jump to the "top of the buffer" and starts afresh?

Im not too certain, but it appears that the players re-join at the end of the buffer, perhaps around where they left off, only to soon get kicked out again... And on it goes until the users changes mounts, or network congestion eases...

[karlH]

If it's a reconnection then the new connection joins at the burst-size into the queue.

karl.

[stereotype]

[karlH]

Depends on what you have as burst. If the queue size is 8Meg and burst is 64k then no, not right at the end, it such a case it would be 64k from the beginning (or the most recent block received). If the burst was 7.99Meg then yes it would be but you should never have the burst and queue sizes too similar.

karl.