Hi list,
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:
[encoder] [encoder]
\ /
[back-end node]
| | | |
[fn1][fn2][fn3][fn4]
I have two active encoders, one is encoding to the active mount and one is
encoding to the fallback mount on the back-end node. Configuration of the
mounts is as follows:
<mount>
<mount-name>/activemount.mp3</mount-name>
<fallback-mount>/fallbackmount.mp3</fallback-mount>
</mount>
<mount>
<mount-name>/fallbackmount.mp3</mount-name>
</mount>
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>
<username>XXX</username>
<password>XXX</password>
</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:
[2010-10-18 13:35:57] DBUG stats/modify_node_event update node server_id
(Icecast 2.3.2)
[2010-10-18 13:35:57] DBUG stats/modify_node_event update node host
(icecast.mydomain.tld)
[2010-10-18 13:35:57] DBUG stats/modify_node_event update node location
(Earth)
[2010-10-18 13:35:57] DBUG stats/modify_node_event update node admin
(icemaster at localhost)
[2010-10-18 13:35:58] DBUG slave/_slave_thread checking master stream list
[2010-10-18 13:35:58] DBUG source/source_apply_mount Applying mount
information for "/activemount.mp3"
[2010-10-18 13:35:58] DBUG format-mp3/format_mp3_apply_settings sending
metadata interval 16000
[2010-10-18 13:35:58] DBUG format-mp3/format_mp3_apply_settings charset
ISO8859-1
[2010-10-18 13:35:58] DBUG source/source_update_settings public set to 0
[2010-10-18 13:35:58] DBUG source/source_update_settings max listeners to
-1
[2010-10-18 13:35:58] DBUG source/source_update_settings queue size to
102400
[2010-10-18 13:35:58] DBUG source/source_update_settings burst size to
65536
[2010-10-18 13:35:58] DBUG source/source_update_settings source timeout to
10
[2010-10-18 13:35:58] DBUG source/source_update_settings fallback_when_full
to 0
[2010-10-18 13:35:58] DBUG stats/modify_node_event update node listenurl (
http://icecast.mydomain.tld:80/activemount.mp3)
[2010-10-18 13:35:58] DBUG stats/modify_node_event update node
listener_peak (0)
[2010-10-18 13:35:58] DBUG stats/modify_node_event update node public (0)
[2010-10-18 13:35:58] DBUG stats/modify_node_event update node server_name
(My Station)
[2010-10-18 13:35:58] DBUG stats/modify_node_event update node
server_description (Unspecified description)
[2010-10-18 13:35:58] DBUG stats/modify_node_event update node server_url (
http://www.mystationsurl.nl)
[2010-10-18 13:35:58] DBUG stats/modify_node_event update node genre (Talk)
[2010-10-18 13:35:58] DBUG stats/modify_node_event update node bitrate
(192)
[2010-10-18 13:35:58] DBUG stats/modify_node_event update node server_type
(audio/mpeg)
[2010-10-18 13:35:58] DBUG stats/modify_node_event update node
max_listeners (unlimited)
[2010-10-18 13:36:00] DBUG client/client_read_bytes reading from connection
has failed
[2010-10-18 13:36:00] DBUG stats/modify_node_event update node clients (2)
[2010-10-18 13:36:00] DBUG stats/modify_node_event update node connections
(2099)
[2010-10-18 13:36:00] DBUG stats/modify_node_event update node clients (1)
As you can see the meta data of the stream is retrieved, but it keeps on
telling the connection has failed and the streams are not working.
Do you have any suggestions on how to solve this problem?
Thanks in advance.
Bart
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20101018/b8c131e2/attachment.htm
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.