[Icecast] Client ... has fallen too far behind, removing - but only when listening to a relay, not when listening to fallback
thomas.ruecker at tieto.com
Sun Mar 17 00:11:33 PDT 2013
On 17/03/13 01:02, Nathan Roberts wrote:
> I have an icecast server (B) which relays another icecast server (A).
> Server B is configured to play a local fallback file when server A is
> unavaliable. Both are version 2.3.3
> When I listen to server B (the relay), while server A is turned off,
> all works fine ie I can listen to the fallback track without problem.
> However if I listen to Server B while server A is running then I
> quickly get:
> INFO source/send_to_listener Client 0 (xx.xx.xx.xx) has fallen too far
> behind, removing
> where xx.xx.xx.xx is my listening IP address (server A and B being
> remote, server B with a good internet connection (Amazon EC2), and
> Server A having a more patchy internet connection - hence the reason
> for using a relay with fallback.
This means that likely the listener client has fallen behind more than
queue size for some reason.
What is the queue-size you have configured?
Also note that in case of fallback to file icecast does actually simply
serve a file like a http server with next to no throttling and will
probably not check queue-size.
> My internet connection is reliable ADSL, the stream is 64k, and given
> the relaibility when on fallback, it doesnt appear credible that the
> listening connection has a problem. Any advice on where to start
> looking much appreciated. Searches of the mailing list haven't shouwn
> anything that appears relivant.
You mention it to be hosted on EC2. I'm not 100% sure if that is a good
place to host an icecast server, but have no personal experience to base
I'd check queue-size first. Maybe set Icecast log level to debug to see
if there is anything else going on.
More information about the Icecast