On Fri, 09 Oct 2015 09:05:05 +0000, you wrote:>reflum, > >On Thu, 2015-10-08 at 14:52 -0400, Steve Matzura wrote: >> Additional to my earlier post, I was also thinking of a single >> broadcast relay, but it's not possible to start it and stop it on >> demand. One way around this might be to load a special Icecast XML >> with the relay in it at the program's broadcast time, then reload the >> regular one when the relayed program ends. Klugey, but it could work I >> suppose. > >Hm. >I think you should go with fallbacks. At least you would not need to >change the config and stuff (and lose listener in case something doesn't >work (e.g. network hiccup between provider and relay)).Good thought.>What is the trigger source for you to change to the other stream?Just a timed program, starts streaming at a certain time, stops when it's over.
Good morning, On Fri, 2015-10-09 at 10:42 -0400, Steve Matzura wrote:> On Fri, 09 Oct 2015 09:05:05 +0000, you wrote: > > >reflum, > > > >On Thu, 2015-10-08 at 14:52 -0400, Steve Matzura wrote: > >> Additional to my earlier post, I was also thinking of a single > >> broadcast relay, but it's not possible to start it and stop it on > >> demand. One way around this might be to load a special Icecast XML > >> with the relay in it at the program's broadcast time, then reload the > >> regular one when the relayed program ends. Klugey, but it could work I > >> suppose. > > > >Hm. > >I think you should go with fallbacks. At least you would not need to > >change the config and stuff (and lose listener in case something doesn't > >work (e.g. network hiccup between provider and relay)). > > Good thought.> >What is the trigger source for you to change to the other stream? > > Just a timed program, starts streaming at a certain time, stops when > it's over.Ok. Then I think we should go for fallbacks and some kind of active rely. There have been some suggestions on such software on the mailing list lately... The documentation for fallbacks can be as part of the regular Icecast2 docs (e.g. on the website). Have a nice day! -- Philipp. (Rah of PH2) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part Url : http://lists.xiph.org/pipermail/icecast/attachments/20151013/357345e7/attachment.pgp
Thanks all for the possibilities for re-streaming. I found something called streamTranscoderv3 (yes, capital-T in Transcoder) that does the job. On Tue, 13 Oct 2015 04:58:20 +0000, you wrote:>Good morning, > >On Fri, 2015-10-09 at 10:42 -0400, Steve Matzura wrote: >> On Fri, 09 Oct 2015 09:05:05 +0000, you wrote: >> >> >reflum, >> > >> >On Thu, 2015-10-08 at 14:52 -0400, Steve Matzura wrote: >> >> Additional to my earlier post, I was also thinking of a single >> >> broadcast relay, but it's not possible to start it and stop it on >> >> demand. One way around this might be to load a special Icecast XML >> >> with the relay in it at the program's broadcast time, then reload the >> >> regular one when the relayed program ends. Klugey, but it could work I >> >> suppose. >> > >> >Hm. >> >I think you should go with fallbacks. At least you would not need to >> >change the config and stuff (and lose listener in case something doesn't >> >work (e.g. network hiccup between provider and relay)). >> >> Good thought. > > >> >What is the trigger source for you to change to the other stream? >> >> Just a timed program, starts streaming at a certain time, stops when >> it's over. > >Ok. Then I think we should go for fallbacks and some kind of active >rely. There have been some suggestions on such software on the mailing >list lately... > >The documentation for fallbacks can be as part of the regular Icecast2 >docs (e.g. on the website). > >Have a nice day!