[Icecast] fallen too far behind, removing

[Roman]

Hi,

For some reason I see this in my logs:

[2016-08-02  12:43:02] INFO source/send_to_listener Client 169 (127.0.0.1)
has fallen too far behind, removing

The more interesting is that it is the ffmpeg, that is listening to the
source stream being removed.

My setup is:

Stream generator:
DEVA TX, streaming 44,1 khz PCM (pcm16le) stream to icecast2 server
Transcoding:
VM with ffmpeg reading this stream from source mountpoint and transcodes it
to 3 MP3 streams (320, 192, 96 kbps)

Using: Icecast 2.4.2
ffmpeg: version N-50577-g777b305-static

I've tried two different VMs and two different DEVA TX devices to
troubleshoot this issue, but I've gave up.

I've also tried to get this stream with ffmpeg first, than transcode to
same streams. The result was the same.

I actually run two different setups at this moment: production and testing.
Both run same  versions and different HW and VMs are on different physical
hosts

To avoid total disconnects of clients in production, I run a backup
mountpoint that plays saved stream file, when source listener gets
disconnected. At this moment all listeners are being moved to the /backup
stream and than back, when source listener connects again. To reconnect I
use a local small php script, that cheks every second if ffmpeg stream is
running. If not - sends me an e-mail and restarts the ffmpeg.

I understand that some listeners could be removed due to latency, network
errors or something like that. But I'm speaking of ffmpeg main stream
listener, that connects from same physical network (different subnets) in
case of Test env and from perfect (if we speak of latency) place in
productions (same physical devices between listener and deva tx, but
different subnets)

Any ideas or help to debug this one?

ffmpeg line at testing VM: (for production it generates 3 streams instead
of 1 here)

#!/bin/sh -e
su vlc -c "FFREPORT=file=/home/vlc/`date +%Y-%m-%d-%H-%M-%S`-mp3.log screen
-A -m -d -S ffMP3 /home/vlc/ffmpeg/latest/ffmpeg -f s16le -ar 44100 -ac 2
-timeout 2000000 -i http://localhost:8500/source -reconnect_at_eof
-reconnect_streamed -b:a 192k -compression_level 0 -ac 2 -ar 44100 -af
"volume=3dB" -f mp3 -ice_name 'LiveFM @ 192' icecast://source:pass@localhost
:8500/LiveFM_320"

icecast.xml

<icecast>
    <limits>
        <clients>1000</clients>
        <sources>3</sources>
        <threadpool>5</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>10</source-timeout>
        <burst-on-connect>1</burst-on-connect>
        <burst-size>65535</burst-size>
    </limits>

    <mount>
      <mount-name>/backup</mount-name>
        <hidden>1</hidden>
      <server_name>backup</server_name>
      <charset>UTF8</charset>
        <no-yp>1</no-yp>
    </mount>



    <mount>
      <mount-name>/LiveFM_320</mount-name>
      <charset>UTF8</charset>
      <password>secret</password>
        <fallback-mount>/backup</fallback-mount>
       <fallback-override>1</fallback-override>
        <no-yp>1</no-yp>
    </mount>



-- 
Best regards,
Roman.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20160802/417c463f/attachment.htm>