[Icecast] Stream fallbacks/spillovers/splashing

[Ricardo Meechan]

The fallback feature works perfectly for us. I don't see anything that
would be considered a bug.

We have 3 streams, /stream /mp3 /live

/stream always fallsback to /live
/live always fallsback to /mp3
/mp3 is always playing random mp3's from the collection (always on)

People listen to the stream using /stream
If a dj connects to /live then the people listening to /stream will hear
the dj. When he disconnects they automatically fallback to /mp3.

One of the best features that icecast has to offer (along with relay
ondemand)



Kind regards.
Rico.






The Ultralon Group will be exhibiting at The Education Show Birmingham between 9th-11th March stand No B10 Hall 12.
www.education-show.co.uk



Wilson & Garden
Ricardo Meechan
IT Administrator
17-21 Newtown Street
Kilsyth
Glasgow G65 0JX
mail: r.meechan at wilsonandgarden.com
www: http://www.wilsonandgarden.com
tel: 01236 823291
fax: 01236 825683
mob: 07966 484371

-----Original Message-----

From: icecast-bounces at xiph.org [mailto:icecast-bounces at xiph.org] On
Behalf Of Karl Heyes
Sent: 03 March 2006 3:56 PM
To: Geoff Shang
Cc: icecast at xiph.org; Dan Regalia
Subject: Re: [Icecast] Stream fallbacks/spillovers/splashing

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.

_______________________________________________
Icecast mailing list
Icecast at xiph.org
http://lists.xiph.org/mailman/listinfo/icecast