I just was looking at the CVS nightly build of the icecast2\src\source.c and see that the mountpoint fallback is now implemented (compared to the 2.0.0 release's source.c) I was hoping to use this feature to support a multi-home radio station that has a master mountpoint stream and offsite "guest" mountpoints. These guest mountpoints would attach on a scheduled based and, theoretically, the main mountpoint would stop broadcasting so the guest mountpoint would take over. Then, when the main mountpoint would want to regain control, start it's stream back up and a switchover from the fallover to the main mountpoint would occur. Would this work? If not, would it be hard to change the code to do this? I figure the hard part would be to dynamically load different XML config files for changing the guest mountpoints. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Hi, I don't see a need to reload the XML file. You can have one that defines all possible mountpoints at once loaded at all times. Mea culpa, I still haven't finished the docs. Fallbacks can be chained and Icecast will walk the chain and collect fallback listeners. So, you can define it like this: Master mountpoint, fallback is slave 1 Slace 1, fallback is slave 2 etc... Any higher mountpoint will preempt all lower ones. Listeners will always connect to the master mountpoint, which is the only one publicly known. Melanie On 2004.03.18 22:00 Gnosis wrote:> I just was looking at the CVS nightly build of the icecast2\src\source.c > and see that the mountpoint fallback is now implemented (compared to the > 2.0.0 release's source.c) > > I was hoping to use this feature to support a multi-home radio station > that has a master mountpoint stream and offsite "guest" mountpoints. > These guest mountpoints would attach on a scheduled based and, > theoretically, the main mountpoint would stop broadcasting so the guest > mountpoint would take over. Then, when the main mountpoint would want to > regain control, start it's stream back up and a switchover from the > fallover to the main mountpoint would occur. > > Would this work? If not, would it be hard to change the code to do this? > I figure the hard part would be to dynamically load different XML config > files for changing the guest mountpoints. >--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Friday 19 March 2004 08:00, Gnosis wrote:> I just was looking at the CVS nightly build of the icecast2\src\source.c > and see that the mountpoint fallback is now implemented (compared to the > 2.0.0 release's source.c) > > I was hoping to use this feature to support a multi-home radio station that > has a master mountpoint stream and offsite "guest" mountpoints. These > guest mountpoints would attach on a scheduled based and, theoretically, the > main mountpoint would stop broadcasting so the guest mountpoint would take > over. Then, when the main mountpoint would want to regain control, start > it's stream back up and a switchover from the fallover to the main > mountpoint would occur. > > Would this work? If not, would it be hard to change the code to do this? > I figure the hard part would be to dynamically load different XML config > files for changing the guest mountpoints.Yes, this would work. There should be no need to dynamically load different config files (though you might choose to set it up like that), but that should work fine anyway. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.