[Icecast] Icecast relay/fallback problem

[Geoff Shang]

On Mon, 18 Oct 2010, brt prt wrote:

> I'm having some problems with my new Icecast setup and I was hoping you can
> help me with it. My Icecast setup looks like this:

[snip]
> <mount>
>            <mount-name>/activemount.mp3</mount-name>
>            <fallback-mount>/fallbackmount.mp3</fallback-mount>
> </mount>

If you want clients to return to the active mount when it returns, you'll 
want a fallback-overide item in there as well.

> <mount>
>             <mount-name>/fallbackmount.mp3</mount-name>
> </mount>

Note that this does absolutely nothing and can be removed.

> The front-end nodes are all relaying the mount from the back-end node.
> Configuration of the mount on the front-end nodes is as follows:
>
> <relay>
>          <server>back-end node ip</server>
>          <port>back-end node port</port>
>          <mount>/activemount</mount>

Presumably this is /activemount.mp3 or you've changed the names of your 
mounts for this Email.

>          <username>XXX</username>
>          <password>XXX</password>

What are these meant to do?  There's no listener authentication stuff in 
your back-end server mount configuration.

> </relay>
>
> The idea is when the primary encoder fails the signal of the stream is still
> available through the fallback mount. The front-end nodes should be moved to
> the fallback mount. I appears the front-end nodes are moved to the fallback
> mount, because the are showing meta data of the streams (sent by the
> encoders), but none of the streams are working. Here is some output from the
> error log on one of the front-end nodes:

A couple of questions:

1.  Does your active and fallback streams use the same MP3 encoder 
parameters?  This is essential if this is going to work.  Note that MP3 is 
not designed for this and may fail at this anyway.

2.  Have you tried using a player to listen to your backup server in the 
same way as your front-end server does?  Does it fallback as it's meant 
to?

You may find that due to the possible flakiness of doing this with MP3, 
you may not be able to get this to work  reliably.  What you may want to 
consider then is having both active and fallback mounts replicated on your 
front-end server, and make the fallback relay on demand so that it only 
pulls when needed.  This means that the mount switching will happen on 
your front server instead of your back-end one, and if there's any 
glitching it'll happen in your listener's player instead of your server. 
The listener can restart the stream if this happens.

Geoff.