[Icecast] Server kicking clients off

Fri Apr 28 21:49:00 UTC 2017

hey,

 I cast itself can not re encode a stream, you would have to use something
like dark ice or vlc to set up as a listener and then source the new
encoded stream on another mount point.  The external program will encode
the stream in what ever format is needed. Mp3 are private and can run into
use laws and Ogg is ope n to use. I not seen any body taken town because of
it yet.

I would worry more about the internet latency then worry about much latency
is added with re encoding. Offering slower encoding should help out those
who don't have faster internet.

DAvid.

On Fri, Apr 28, 2017 at 11:11 AM, Jack Elliott <thatjackelliott at kpov.org>
wrote:

> "Live streams are not live, they can be up to 15 to 20 sec off original
> encoding."
>
> Something you become aware of very quickly when you're announcing into a
> mic and have to wait to hear your words!
>
> We do a bit of pre-show calibration with folks at the station to determine
> how long the delay ("latency" in digital-speak) is at the start of the
> remote broadcast, and start our remote announcing that number of seconds
> before the start of the show so they come out of the buffers at the right
> time. And at the end of the remote's broadcast day, we do the same as
> latency tends to build up over the period of the show. We often say, "and
> thank you for listening," a full 30 seconds before the scheduled end of the
> remote so that the studio programming can take over at the scheduled time.
>
> For our setup there are two listen-clients: we knuckleheads monitoring at
> the remote event, and a listen-client at the studio, which feeds the
> broadcast console and thence to our radio listeners. The listen client at
> the station won't fall too far behind because it's on the same LAN as the
> Icecast server. It's us knuckleheads out at the remote, checking in with
> the stream to assure that our stream is getting to the server, who can get
> kicked off due to falling too far behind.
>
> For music-grade stereo sound we encode to 192kbps mp3. Ogg might be
> better-sounding, but they use iTunes and/or Windows Media Player at the
> station to play the stream and mp3 is your lowest common denominator. They
> fear change at the studio.
>
> *Question*: can the icecast server be set up with two listen-client
> mountpoints? Both using the same source-client mountpoint, with one
> listen-client mountpoint for studio playback at the encoded bitrate, and a
> second listen-client mountpoint re-encoded to a lower bitrate for us
> knuckleheads to use at the remote end to monitor? That may add additional
> latency for the re-encoding but it might be more reliable.
>
> --
> 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/27/2017 08:36 AM, David Saunders wrote:
>
> Hey,
>
>   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
> behind.
> 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.
>
> David.
>
>
>
> On Thu, Apr 27, 2017 at 12:58 AM, Jack Elliott <thatjackelliott at kpov.org>
> wrote:
>
>> 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 <%28541%29%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 <%28541%29%20848%207021>
>>> 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/20170428/ed855ab0/attachment.htm>