[Icecast] Client has fallen too far behind

[Milton Huang]

Thanks for the input. It helps a lot. I've got a stream I'm continuously
generating from a server, and our team is planning to build a mobile app to
access and play it. Your comments are getting me to think about what type
of monitoring we want to put on the client end, especially since we want
the stream to be constantly 'live' (i.e. the users can't pause the stream -
they can only rejoin the current stream so that everyone is listening to
the same thing as close as possible given network connection limitations).

I'm sure I'll have a lot more questions as we try to ramp up and add relays
and distribute our signal to distant locations!


On Thu, Oct 14, 2021 at 5:28 PM Ross Levis <ross at stationplaylist.com> wrote:

> Another possible reason is the speed of the encoding is different to the
> speed of the playback device. Hardware soundcard chips are
> often responsible for the speed of encoding and playback, and these are
> not 100% accurate.  Although more accurate than computer
> clocks.
>
> We have an Icecast stream being played by a dedicated playback device used
> for a studio to transmitter link, and it gets further and
> further behind over several days or weeks of continuous play. Occasionally
> there is a pause when Icecast drops the stream and the
> device reconnects. This is on a local network so not related to bandwidth
> issues.
>
> For others, the opposite is also possible where the playback device is
> playing slightly slower than the encoder and the playback
> buffer eventually gets full and the playback device has to drop some audio
> causing a short skip.
>
> -----Original Message-----
> From: Icecast [mailto:icecast-bounces at xiph.org] On Behalf Of Marvin Scholz
> Sent: Friday, 15 October 2021 7:19 am
> To: Icecast streaming server user discussions
> Subject: Re: [Icecast] Client has fallen too far behind
>
>
>
> On 14 Oct 2021, at 19:22, Milton Huang wrote:
>
> > I'm new to Icecast and this mailing list. I have set it up to run a
> > continuous (unending) audio stream that is being generated by a Python
> > script.  In my log I found an entry that said:
> >
> > [2021-09-17  06:03:53] INFO source/send_to_listener Client 620
> > (XX.XX.XX.XXX) has fallen too far behind, removing
> >
> > The user gets kicked, and the listener count decreases.
> >
> > What does this mean? Is the client pausing too long or getting out of
> > sync
> > somehow?
>
> Hi,
>
> clients falling behind can have various reasons. Generally it means that
> the listener client is at the end of Icecasts buffer, the size of which
> is
> configured with the queue-size option in the icecast.xml.
>
> One reason for the client falling behind could be that the client is on
> a slow network connection and can therefore not keep up with the live
> stream.
>
> Depending on how the client is implemented, it could be that it indeed
> does not handle pausing properly, though with most clients that
> shouldn't
> be an issue anymore.
>
> Yet another although rarer reason could be that you are streaming with a
> very
> high bandwidth, like for a video stream and did not adjust the buffer to
> be large enough.
>
> > What is the best way for me to learn what is happening, and how to
> > prevent
> > it?
>
> There is not much you can do about without knowing exactly the reason
> why
> the specific client disconnected. And even then, as described above
> might
> be just a slow network connection. Seeing these messages about a client
> being dropped is not that unusual.
>
> However if you can reproduce this with your listener client, then you
> should check
> the logs of the client
>
> > _______________________________________________
> > 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
>
>
> _______________________________________________
> 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/20211023/2e16f1d3/attachment.htm>