[Icecast] Icecast relay/fallback problem
geoff at QuiteLikely.com
Mon Oct 18 10:49:36 PDT 2010
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:
If you want clients to return to the active mount when it returns, you'll
want a fallback-overide item in there as well.
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:
> <server>back-end node ip</server>
> <port>back-end node port</port>
Presumably this is /activemount.mp3 or you've changed the names of your
mounts for this Email.
What are these meant to do? There's no listener authentication stuff in
your back-end server mount configuration.
> 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
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.
More information about the Icecast