<div dir="ltr">Hey, <div><br></div><div> Something about streaming. </div><div> </div><div> 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.</div><div><br></div><div>You can help this by maxing out the following settings: </div>queue-size : This is the buffer you want to allow the client to fall behind. <div>burst-size: This is how much data you want to fill send to the client when they connect to fill up the client buffers. </div><div><br></div><div>You can also provide a lower quality stream(lower bandwidth) for those who have bad connections. </div><div><br></div><div> 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. </div><div><br></div><div> 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. </div><div><br></div><div>David.</div><div><br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 27, 2017 at 12:58 AM, Jack Elliott <span dir="ltr"><<a href="mailto:thatjackelliott@kpov.org" target="_blank">thatjackelliott@kpov.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>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.</p>
<p>For Icecast2 content, when Icecast kicks a client off for being
"too far behind" -- what is "too far"?<br>
</p><span class="">
<pre class="m_2148754537603914082moz-signature" cols="72">--
That Jack Elliott
<a href="tel:(541)%20848-7021" value="+15418487021" target="_blank">(541) 848 7021</a>
KPOV 88.9 FM High Desert Community radio
Producer, The Wednesday Point
Host, The Sunday Classics
</pre>
</span><div><div class="h5"><div class="m_2148754537603914082moz-cite-prefix">On 04/26/2017 08:10 PM, Brad Isbell
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.<br>
<div class="gmail_extra"><br clear="all">
<div>
<div class="m_2148754537603914082gmail_signature" data-smartmail="gmail_signature">Brad Isbell<br>
<a href="mailto:brad@musatcha.com" target="_blank">brad@musatcha.com</a><br>
<a href="http://www.musatcha.com" target="_blank">http://www.musatcha.com</a></div>
</div>
<br>
<div class="gmail_quote">On Wed, Apr 26, 2017 at 1:58 PM, Jack
Elliott <span dir="ltr"><<a href="mailto:thatjackelliott@kpov.org" target="_blank">thatjackelliott@kpov.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's
behaving as it is meant to: if a listen client gets too
far behind, Icecast2 server is kicking them off.<br>
<br>
error.log says,<br>
<br>
"INFO source/source.c Client 120 (xxx.xxx.xxx.xxx) has
fallen too far behind, removing"<br>
<br>
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>.<br>
<br>
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.<br>
<br>
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.<span class="m_2148754537603914082HOEnZb"><font color="#888888"><br>
<br>
-- <br>
That Jack Elliott<br>
<a href="tel:%28541%29%20848%207021" value="+15418487021" target="_blank">(541) 848 7021</a><br>
KPOV 88.9 FM High Desert Community radio<br>
Producer, The Wednesday Point<br>
Host, The Sunday Classics<br>
<br>
______________________________<wbr>_________________<br>
Icecast mailing list<br>
<a href="mailto:Icecast@xiph.org" target="_blank">Icecast@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/" target="_blank">http://lists.xiph.org/mailman/</a><wbr>listinfo/icecast<br>
</font></span></blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div></div></div>
<br>______________________________<wbr>_________________<br>
Icecast mailing list<br>
<a href="mailto:Icecast@xiph.org">Icecast@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/icecast" rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/<wbr>listinfo/icecast</a><br>
<br></blockquote></div><br></div>