[Icecast] Server kicking clients off

David Saunders abitar.com at gmail.com
Thu Apr 27 15:36:07 UTC 2017


  Something about streaming.

        Live streams are not live, they can be up to 15 to 20 sec off
original encoding.  This is to to overhead on both the server and client
for encoding/decoding the stream, Any trans coding, and and buffering that
has to be done on a "slow" connection. Unless the client decoder has some
way to sync the stream, this delay will grow tell icecast server decides I
have no more buffer t back into and drops them.  This can be really
pronounced if the connection jumps through a satellite.

You can help this by maxing out the following settings:
queue-size :    This is the buffer you want to  allow the client to fall
burst-size:        This is how much data you want to fill send to the
client when they connect to fill up the client buffers.

You can also provide a lower quality stream(lower bandwidth) for those who
have bad connections.

 What I do is if we get allot of slow listeners, I go though the log
determined how many unique one are falling out of the queue.  And tweak up
the queue size or offer a lower quality connection to them when they
connect again :)  Since we from time to time have issues with connection
spammers. (They connect to the server 1000/sec, and the slow listens sky
rocket) I use a php traffic controller and black list on the icecast server
to insure the best experience for our listeners.

  Just remember, setup the streams at the lowest possible encoding as you
can.  There are people who still are not on broadband connections around
the world.


On Thu, Apr 27, 2017 at 12:58 AM, Jack Elliott <thatjackelliott at kpov.org>

> Thanks, Brad -- I first turned to VLC but my stream-client device is a
> Raspberry Pi 3, and there doesn't seem to be a build for the device. That
> said, I just stumbled across mpg123, a command-line mp3/stream player that
> has audio buffer and timeout setting which so far looks quite robust.
> For Icecast2 content, when Icecast kicks a client off for being "too far
> behind" -- what is "too far"?
> --
> That Jack Elliott(541) 848 7021 <(541)%20848-7021>
> KPOV 88.9 FM High Desert Community radio
> Producer, The Wednesday Point
> Host, The Sunday Classics
> On 04/26/2017 08:10 PM, Brad Isbell wrote:
> Simply use VLC and put it on repeat.  If a connection is lost during
> playback, it will reconnect and pick up in the current live position, like
> you have suggested, without stopping.  If it cannot reconnect after 3
> times, it goes to the next playlist item.  If the playlist is on repeat, it
> runs indefinitely.
> Brad Isbell
> brad at musatcha.com
> http://www.musatcha.com
> On Wed, Apr 26, 2017 at 1:58 PM, Jack Elliott <thatjackelliott at kpov.org>
> wrote:
>> It's behaving as it is meant to: if a listen client gets too far behind,
>> Icecast2 server is kicking them off.
>> error.log says,
>> "INFO source/source.c Client 120 (xxx.xxx.xxx.xxx) has fallen too far
>> behind, removing"
>> I don't see a setting in icecast.xml that sets the value for "too far
>> behind". I'm guessing it's related to <queue-size>.
>> I wish Icecast could dump the buffer and bring the listen-client back up
>> to date instead of dumping the client. The reason being that when network
>> congestion causes Icecast to kick my listen-client off, the client
>> application just gives up. And this is a listen-client I'd like to have
>> running 24/7 so I can monitor the station's backroom server when we are
>> doing all-day music remotes.
>> I haven't found a media/url player that attempts re-connect when kicked
>> off. At least under Linux. On Windows a player called AIMP3 works great: if
>> it is disconnected from the server, it tries to reconnect. Over and over
>> and over. I like that behavior.
>> --
>> That Jack Elliott
>> (541) 848 7021
>> KPOV 88.9 FM High Desert Community radio
>> Producer, The Wednesday Point
>> Host, The Sunday Classics
>> _______________________________________________
>> Icecast mailing list
>> Icecast at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20170427/bf1b5204/attachment.htm>

More information about the Icecast mailing list