Icecast - Mar 2013 - Client ... has fallen too far behind, removing - but only when listening to a relay, not when listening to fallback

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.

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.

Regards

Nathan

Hi Nathan,

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 
this on.

I'd check queue-size first. Maybe set Icecast log level to debug to see 
if there is anything else going on.

Cheers

Thomas