| View previous topic :: View next topic |
| Author |
Message |
boteman
Joined: 04 Dec 2009
Posts: 8
Location: south FLA, USA
|
 Posted: Wed Dec 01, 2010 5:38 am Post subject: fallback to wrong mount point |
 |
|
I operate 3 streaming scanner feeds through Icecast 2.3.2 on a linux box hosted at a co-lo facility.
I have 3 mount points defined, each with a recorded fallback mp3 that is the same format as the associated live stream.
Two of the mount points fall back to the recording properly when the live stream stops, but one (botekyw) falls back to the music for a brief time then switches to one of the other live feeds! I do not want this behavior.
I have juggled the order in which the mount definitions appear in icecast.xml to no avail.
Is this a known problem or do I have gremlins in my server?
Here is the pertinent section of my icecast.xml
| Code: |
<mount>
<mount-name>/botekyw</mount-name>
<!-- this is the feed that falls back to /botewild -->
<intro>/bote/kyw.mp3</intro>
<fallback-mount>/bote/clock.mp3</fallback-mount>
<fallback-override>1</fallback-override>
<fallback-when-full>1</fallback-when-full>
<max-listeners>20</max-listeners>
<stream-url>http://www.trackstreamer.com</stream-url>
<burst-size>0</burst-size>
</mount>
<mount>
<mount-name>/botemixer</mount-name>
<intro>/bote/mixer.mp3</intro>
<fallback-mount>/bote/clock11kc.mp3</fallback-mount>
<fallback-override>1</fallback-override>
<fallback-when-full>1</fallback-when-full>
<max-listeners>20</max-listeners>
<burst-size>0</burst-size>
</mount>
<mount>
<mount-name>/botewild</mount-name>
<!-- this is the feed that gets fallback listeners from /botekyw-->
<intro>/bote/wild.mp3</intro>-
<fallback-mount>/bote/clock.mp3</fallback-mount>
<fallback-override>1</fallback-override>
<fallback-when-full>1</fallback-when-full>
<max-listeners>20</max-listeners>
<stream-url>http://www.trackstreamer.com</stream-url>
<burst-size>0</burst-size>
</mount>
<mount>
<mount-name>/mixermoved</mount-name>
<intro>/bote/ftl_moved.mp3</intro>
<fallback-mount>/bote/ftl_moved.mp3</fallback-mount>
<fallback-override>0</fallback-override>
<fallback-when-full>1</fallback-when-full>
<max-listeners>2</max-listeners>
<max-listener-duration>120</max-listener-duration>
<burst-size>8192</burst-size>
</mount>
|
Thanks for any suggestions you might have. |
|
| Back to top |
|
 |
karlH
Code Warrior
Joined: 13 Jun 2005
Posts: 5476
Location: UK
|
| Posted: Wed Dec 01, 2010 3:03 pm Post subject: |
|
|
so botekyw and botewild fall back to the same thing /bote/clock.mp3 and the listeners end up on the next one of those that starts up.
You could copy/link the file to some other name, specify the alternate filename on one of those for the fallback and that should keep the listeners separate.
karl. |
|
| Back to top |
|
|
boteman
Joined: 04 Dec 2009
Posts: 8
Location: south FLA, USA
|
| Posted: Wed Dec 01, 2010 4:01 pm Post subject: |
|
|
| karlH wrote: |
so botekyw and botewild fall back to the same thing /bote/clock.mp3 and the listeners end up on the next one of those that starts up.
You could copy/link the file to some other name, specify the alternate filename on one of those for the fallback and that should keep the listeners separate.
karl. |
DOH! I was thinking of the recorded message as just that, a mere recording and not a mount point as in a live stream.
Also, I have read other situations here where you suggest a local relay mount point to solve certain problems. Is there a wiki or documentation that expands on setting up a local relay or is everything that is needed already documented in the stock icecast.xml file? I'm looking more for possibilities and applications rather than configuration instructions.
Thank you for your help! |
|
| Back to top |
|
|
karlH
Code Warrior
Joined: 13 Jun 2005
Posts: 5476
Location: UK
|
| Posted: Wed Dec 01, 2010 4:08 pm Post subject: |
|
|
a local relay is just a relay as documented, just referring to a stream already on the server. It can be useful in certain cases if you want to keep listeners on a certain mountpoint. If that fallback you had means that the fallback was a stream then you could duplicate the fallback to another mountpoint to keep listeners separated. Another way is if you alternate between live and playlist but you want to keep a mountpoint fixed for listing on the directory then you could use a local relay to bounce between live and playlist but updates the directory with a fixed mountpoint.
karl. |
|
| Back to top |
|
|
boteman
Joined: 04 Dec 2009
Posts: 8
Location: south FLA, USA
|
| Posted: Fri Dec 03, 2010 3:50 am Post subject: |
|
|
| karlH wrote: |
a local relay is just a relay as documented, just referring to a stream already on the server. It can be useful in certain cases if you want to keep listeners on a certain mountpoint. If that fallback you had means that the fallback was a stream then you could duplicate the fallback to another mountpoint to keep listeners separated. Another way is if you alternate between live and playlist but you want to keep a mountpoint fixed for listing on the directory then you could use a local relay to bounce between live and playlist but updates the directory with a fixed mountpoint.
karl. |
In reading the online documentation I encountered this admonition under fallback-mount:
| Quote: |
| Note that the fallback file is not timed so be careful if you intend to relay this. They are fine on slave streams but don't use them on master streams, if you do then the relay will consume stream data at a faster rate and the listeners on the relay would eventually get kicked off. |
If I specify on-demand = 1 in the relay settings would this preclude trouble with relaying a recorded file when the live source disappears? Or should I just leave things the way they are and be happy?
In my case the recorded file is simply a place-holder to keep users around while my flaky DSL resyncs for a few minutes instead of getting disconnected and going away forever.
Thanks again. |
|
| Back to top |
|
|
karlH
Code Warrior
Joined: 13 Jun 2005
Posts: 5476
Location: UK
|
| Posted: Fri Dec 03, 2010 2:28 pm Post subject: |
|
|
relaying a file will usually not work as you want as the originating file is sent as fast as possible, if the source of the relay throttles the sending of the data to be at the expected bitrate then it could work.
karl. |
|
| Back to top |
|
|
iunderwood
Joined: 23 Aug 2008
Posts: 114
Location: Leicester, MA
|
| Posted: Thu Dec 09, 2010 1:09 pm Post subject: |
|
|
You could also set up the ezstream utility to stream the fallback file to the backup mountpoints. I have found that to work very well, but it seems like you'd need to run three instances of it in order to cover each point.
_________________
++I; |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
