Icecast - Jul 2013 - Icecast relay with backup - loops backup for too long

My listeners connect to a publicly accessible Icecast server with the
config below. Between broadcasts it uses a fallback mp3, which loops.
During broadcasts it relays from a local Icecast server that I broadcast to
(config also below). I am aiming for approx 30-45 seconds buffering, as the
connection from public to local icecast server is 'less than ideal'.

The set up is working fine except that if someone connects just before the
broadcast starts, then it appears the fallback file (approx 2.5min) is
queued multiple times, and the delay I've seen can be between 8 and 30
minutes. If they connect just after then the they listen approx 30-45
seconds behind real time as intended. I'd really appreciate any pointers on
where to look into this: is it an Icecast issue (I cant see why) or a
player issue (harder to control, although I can recommend).

Any advice much appreciated.

Thanks

Nathan

*Public Icecast server v 2.3.3 config (extract)*

    <limits>
        <clients>50</clients>
        <sources>2</sources>
        <threadpool>5</threadpool>
        <queue-size>1048576</queue-size>
        <client-timeout>60</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>45</source-timeout>
        <burst-size>65535</burst-size>
    </limits>

    <relay>
        <server>myurl.com</server>
        <port>8000</port>
        <mount>/dores</mount>
        <username>relay</username>
        <password>redacted</password>
        <local-mount>/dores</local-mount>
        <on-demand>1</on-demand>
        <relay-shoutcast-metadata>0</relay-shoutcast-metadata>
    </relay>

    <mount>
        <mount-name>/dores</mount-name>
        <max-listeners>15</max-listeners>
        <dump-file>/var/log/icecast/dores-dump.mp3</dump-file>
        <burst-size>65536</burst-size>
        <fallback-mount>/relayfallback.mp3</fallback-mount>
        <fallback-override>1</fallback-override>
        <fallback-when-full>0</fallback-when-full>
        <hidden>1</hidden>
        <no-yp>1</no-yp>
    </mount>

*Local Icecast server config (extract):*

    <limits>
        <clients>100</clients>
        <sources>2</sources>
        <threadpool>5</threadpool>
        <queue-size>524288</queue-size>
        <client-timeout>30</client-timeout>
        <header-timeout>15</header-timeout>
        <source-timeout>30</source-timeout>
        <burst-on-connect>1</burst-on-connect>
        <burst-size>65535</burst-size>
    </limits>

    <mount>
        <mount-name>/dores</mount-name>
        <max-listeners>3</max-listeners>
       
<dump-file>/usr/local/var/log/icecast/dores-dump.mp3</dump-file>
        <burst-size>65536</burst-size>
        <hidden>1</hidden>
        <no-yp>1</no-yp>
        <authentication type="htpasswd">
                <option name="filename"
value="/usr/local/share/icecast/myauth"/>
                <option name="allow_duplicate_users"
value="1"/>
        </authentication>

    </mount>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20130713/e6d80347/attachment.htm

On Sat, 13 Jul 2013, Nathan Roberts wrote:
> The set up is working fine except that if someone connects just before the
> broadcast starts, then it appears the fallback file (approx 2.5min) is
> queued multiple times, and the delay I've seen can be between 8 and 30
> minutes. If they connect just after then the they listen approx 30-45
> seconds behind real time as intended.
The reason for this is that Icecast will send a static MP3 file as quickly 
as it can, rather than at the correct bitrate.  Whether or not it should 
do something intelligent, possibly by having a configured bit rate, is 
something for debate I guess.

The way to get what you want is to have something streaming your backup 
content.  Something like EZStream would do nicely.

Cheers,
Geoff.

On 07/13/2013 05:58 PM, Geoff Shang wrote:
> On Sat, 13 Jul 2013, Nathan Roberts wrote:
>
>> The set up is working fine except that if someone connects just before
the
>> broadcast starts, then it appears the fallback file (approx 2.5min) is
>> queued multiple times, and the delay I've seen can be between 8 and
30
>> minutes. If they connect just after then the they listen approx 30-45
>> seconds behind real time as intended.
> The reason for this is that Icecast will send a static MP3 file as quickly 
> as it can, rather than at the correct bitrate.  Whether or not it should 
> do something intelligent, possibly by having a configured bit rate, is 
> something for debate I guess.
I think we do some minimal rate limiting, but it's nowhere near what
would be necessary.
Fallback to file is 'lazy' and discouraged for professional
installations anyway.

> The way to get what you want is to have something streaming your backup 
> content.  Something like EZStream would do nicely.
Exactly. And if you just loop a couple of files without re-encoding
them, but send them as is, it doesn't take up any noticeable CPU cycles.


Cheers

Thomas