Icecast - Jun 2010 - [Possible bug] Invalid Switching on fallover?

I may have found a bug... I am not sure. I am new to Icecast, so this might be
how things are meant to be,

I have a Debian install with Icecast2 install from APT - Icecast 2.3.2

I have three mount points (all 128kbp mp3)
/EDH.mp3 (public = 0 and hidden = 1)
/live.mp3 (fallback-mount = /EDH.mp3 and fallback-override = 1)
/dj1.mp3 (fallback-mount = /EDH.mp3, fallback-override = 1, public = 0, and\
hidden = 1)


1) I start a liquidaudio script that transmits to /EDH.mp3
2) I start a listener (tested with itunes and windows media player) on
/live.mp3.m3u
3) I confirm that I hear the music from /EDH.mp3
4) I start broadcast to /dj1.mp3 (tried with liquidaudio, sam, and edcast)
totally different music from the liquidaudio script
5) The music from step 2 is now listening to the audio from /dj1.mp3 instead of
the /EDH.mp3
6) I start broadcasting to /live.mp3 directly
7) the listener from step 2 is still only hearing /dj1.mp3

this appears to be a potential bug with how I understand fallback to be working
if two mount points both fallback with override to the same (third) mount
point... which ever of the two "top" mount points begins broadcasting
first will "take" all the listeners currently on that fallback, no
matter where they came from.

I tested it with removing the fallback from /dj1.mp3 and at step 5, the
listeners still hear music from /EDH.mp3 and did not move to /dj1.mp3.

This seams to be a case of a fallback override moving the users to the first
available stream that fell back to that stream, not to the one that sent them.

 "Can I burn softly, a silent ember?"
Quu
Patrick Bohnet
Demon Kitty Productions
OtakuVideo

On Wed, 2 Jun 2010, Patrick Bohnet wrote:
> this appears to be a potential bug with how I understand fallback to be 
> working if two mount points both fallback with override to the same 
> (third) mount point... which ever of the two "top" mount points
begins
> broadcasting first will "take" all the listeners currently on
that
> fallback, no matter where they came from.
I reported this something like 5 or 6 years ago.  I consider it a bug too 
but apparently it's meant to work like that.

The (IMHO unecessary) solution is to set up a second fallback mount that 
relays the first one so that each mount has its own fallback mount to fall 
back to.

Geoff.