Icecast Streaming Media Server

[sonia]

Hello all and especially Karl,

One question and one sub-question:

a) What are the slow listeners? I've seen them on my stats and usually the number is 3 times up, than the actual! for example if I have 100 listeners live the slow listeners number is up to 350!
b) Is it something on icecast that I must fix? And if yes, can you please tell me exactly and what?

thank youuuuuuuuuuuuuuuuuuuuuu
Sonia
_________________
www.freshwebradio.com

[karlH]

It is the count of listeners that have been dropped by icecast because the stream has not been able to be sent to a listener in time. Like sending a 128k stream down a 56k dialup line. Eventually the data to be sent will back up so much that it exceeds queue-size and then icecast drops them, increasing the slow listeners count in the process.

The count accumulates while the stream is active so don't expect there to be a direct link to listeners. The only settings that would affect this is queue size and burst size. If the queue can be at most 200k and you burst 180k then there isn't much tolerance for temporary glitches. If the stream is an on-demand relay and the source of the relay bursts a large number then that could also push the listener off the queue, think icecast queue of 512k relaying a stream that bursts 1Meg

The only other thing that could cause stalling is network errors or congestion so any problems may not actually be under your control but it is not unknown for icecast to be used for accidental network testing

karl.

[sonia]

thank you so much for all. understood perfectly.
soooo according to what you said, no need to change anything from the following,e?

<limits>
<clients>100000</clients>
<sources>2</sources>
<threadpool>25</threadpool>
<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>98304</burst-size>
</limits>
_________________
www.freshwebradio.com

[karlH]

Those look fine, 128k stream is 16kbyes/s so that would be around 30 seconds lag before they are dropped. The other possible issue is the TCP settings on the server, specifically the send buffer, if the listener is far enough away and the send buffer is not large enough then the connection can be throttled, but this typically only affects win32 servers.

karl.

[sonia]

[robertut]

[karlH]

In listen-socket specify <so-sndbuf>N</so-sndbuf> where N is the TCP send buffer size. From my understanding, many win32 setups only go up to may 8k or so, this may be different on various win32 versions and a global registry may be available but that isn't always the case and may not be suitable if you have other busy apps on there as well.

karl.

[robertut]

[karlH]

Anything above 8k obviously, but the question would depend on what you expect from the listeners connecting. 1000 listeners at 32k each would mean socket buffers of at least 32Meg of real memory (probably more because of administration overhead, could be twice).

karl.

[robertut]

Into which section of config file to put this <so-sndbuf>N</so-sndbuf>? How to specify:

[karlH]

use 32768, I haven't added a converter for size fields like this or burst/queue size. The K and M options work on bitrate fields like max-bandwidth/limit-rate and true/false yes/no 0/1 work on booleans

karl.

[robertut]

Thanks, we'll see how it goes.

[sonia]

Hello Karl and everybody

sorry for ressurecting! this topic, but I want to ask you and tell me your opinion:
Finally, because I see hundreds of slow listeners every day, is it a good idea to broadcast also and a stream lower than 128k? Perhars 64k?
My connection is fine, my server has no problems, so assume that people with low bandwidth lines are trying to listen

And if yes, can it be supported from icecast from the same ip?
If yes to that also, I suppose that I must do some changes to xml, correct?

Please, you know I trust you and I need you to tell me if you agree, disagree and all the changes that I must do, if aaaaaaall the above can proceed.

thank you thank you thank you
Sonia
_________________
www.freshwebradio.com

[karlH]

usually people have a few different bitrate streams so that people can choose, not only bitrate but format as well. icecast has no problem with that but you have to decide what you are comfortable with. Obviously while a lower bitrate stream should reduce the cause of "slow listeners", but playback quality is most likely lowered.

The issue raised originally was specifically with win32 and how that platform handles the sending of the stream data to the listener. At 128k, you may find that the OS is throttling the sending rate from icecast to the listener (if they are far enough away) causing a slow listener event to trigger, even though you may not of saturated your network connection. The so-sndbuf setting could help in such cases.

karl.

[sonia]