Okay, a quick question,
I've got IceCast 2.3.1 setup on a demo server, And I've got some wierd
behavior going on...
Here's the behavior:
I have my constant feed always running on mountpoint: /switch
I have my main stream broadcasting: /stream
someone connects to an alternate named stream: /krushradio
They pull all the listeners from /switch and /stream to their stream.
If the listener (from /stream) refreshes their player, they will begin
listening to whats being broadcast on /stream again
My assumption is that the Fallback-override should only pertain to the
mountpoint in which it is contained, and not the entire server.
Unless the fallback-override should not be used at all, and simply listing
the fallback mount will have it provide the functionality that i want, which
is to have a place for people to go when the regular stream is not in use,
and when it does have a broadcaster, that it moves those listeners back to
the main stream (/krushradio), eg... someone is listening to /krushradio
with no broadcasting (playing /switch) and then I connect to /krushradio to
broadcast, it stops the feed from /switch (being broadcast over /krushradio)
and plays my stream instead.
I hope that makes sense...
Here are the sample configs for the 3 streams:
<mount>
<mount-name>/switch</mount-name>
<mp3-metadata-interval>1200</mp3-metadata-interval>
<burst-on-connect>1</burst-on-connect>
<burst-size>65536</burst-size>
<mp3-metadata-interval>4096</mp3-metadata-interval>
</mount>
<mount>
<mount-name>/stream</mount-name>
<password>hackme</password>
<max-listeners>200</max-listeners>
<intro>/krushradio.mp3</intro>
<fallback-mount>/switch</fallback-mount>
<fallback-override>1</fallback-override>
<fallback-when-full>1</fallback-when-full>
<public>1</public>
<stream-url>http://www.krushradio.com</stream-url>
<burst-on-connect>1</burst-on-connect>
<burst-size>65536</burst-size>
<mp3-metadata-interval>4096</mp3-metadata-interval>
</mount>
<mount>
<mount-name>/krushradio</mount-name>
<password>hackmemore</password>
<max-listeners>200</max-listeners>
<intro>/krushradio.mp3</intro>
<fallback-mount>/stream</fallback-mount>
<fallback-override>1</fallback-override>
<fallback-when-full>1</fallback-when-full>
<public>1</public>
<stream-url>http://www.krushradio.com</stream-url>
<burst-on-connect>1</burst-on-connect>
<burst-size>65536</burst-size>
<mp3-metadata-interval>4096</mp3-metadata-interval>
</mount>
Thanks for your help in advance!
~DocNasty
~Krushradio.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20060303/fbf0bf57/attachment.htm>
Dan Regalia wrote:> My assumption is that the Fallback-override should only pertain to the > mountpoint in which it is contained, and not the entire server.You have found what I consider to be a bug in Icecast, though there seems to be no willingness to fix this. If you have a stream which is a fallback for more than one source, any listener which fell back to it will be pulled forward to any source for which the stream was a fallback. Example: You have two streams, /stream1.ogg and /stream2.ogg, and a fallback called /fallback.ogg. If you have listeners to both /stream1.ogg and /stream2.ogg and both streams stop, all listeners will fall back to/fallback.ogg. Then, if say /stream1.ogg reconects, all listeners will be moved to /stream1.ogg, regardless of whether they originally tuned in to /stream1.ogg or /stream2.ogg. More confusing, if a person who originally tuned into /stream2.ogg, who is now on /stream1.ogg, stops their player and starts it again, they'll drop back through to /fallback.ogg. I filed this as a bug in April last year (http://trac.xiph.org/cgi-bin/trac.cgi/ticket/642). I even suggested how this might be fixed. You'll notice the ticket has been closed. Whilst it's possible to work around the bug, it's clunky in my opinion and Icecast doesn't act in a way a reasonable person would expect it to in this situation. If you would like to work around this bug, take a look at Karl's explanation of how to do this using local relays: http://lists.xiph.org/pipermail/icecast/2005-September/009947.html Geoff.
Geoff Shang wrote:> Dan Regalia wrote: > >> My assumption is that the Fallback-override should only pertain to the >> mountpoint in which it is contained, and not the entire server.the override will take back listeners from the stream that the fallback-mount refers to (or some fallback of that).> > You have found what I consider to be a bug in Icecast, though there > seems to be no willingness to fix this.You're the only one that has said you consider it a bug. ...> I filed this as a bug in April last year > (http://trac.xiph.org/cgi-bin/trac.cgi/ticket/642). I even suggested > how this might be fixed. You'll notice the ticket has been closed. > Whilst it's possible to work around the bug, it's clunky in my opinion > and Icecast doesn't act in a way a reasonable person would expect it to > in this situation.Believe me, the approached you suggested is not as trivial as you may think. Feel free to give a compelling case for why the on-demand relay approach is 'Clunky' over the 'maintain fallback lists for each listener in the server', don't forget about situations other than Dan's where these lists may be triggered. I'd rather have a tag in the <mount> that says the listeners dropping back to the fallback-mount need to be isolated and that creates a hidden on-demand relay automatically. karl.