I have been thinking of something like this for a long time now. Basically
a dual stream switching system. 24/7 radio station being fed from multiple
sources, sources "on deck" get attached to one mount point and when
it's
their time to be "on the air" the main mount drops and falls back to
the
other source, when this source is finished, it switches over to something
else. Perhaps a fallback for a fallback, or even some kind of switching
system built into Icecast.
I'll think about this some more. I think my original idea of using MySQL
and Perl may not be a good one.
-lee
On Thu, 18 Mar 2004, Gnosis wrote:
> After I installed the latest nightly build, it looks like the fallback
works without rebuffering. I do see one problem -- when the main mountpoint
stream restarts, the fallback continues to play. Once I stop the fallback
mountpoint stream, the main mountpoint stream restarts, but only after client
rebuffering
>
> Also, during the mountpoint switchovers, sometimes the meta-data is lost in
the clients.
>
>
> thank you,
> Michael
>
> ________________________________
>
>
> 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.
>
>
>
--- >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.