[icecast-dev] Re: Fwd: More fallback handling

[Melanie]

Hi,

I'm the author of the patch in question. Mike emailed me to say that he was 
not very much convinced the run command features would be useful. He also 
mentioned that the implementatiton is problematic.

Well, to understand the reason for the command execution, one really has to 
know how this patch came about.

I am new to icecast, four days ago I didn't know it existed.

I hooked up with the makers of an internet radio station because of a DJing 
software I wrote that turned out to be useful for broadcasting.

When I was told about the workings of the station, numerousp problems were 
mentioned regarding sender connection and lost listeners.

Nobody had a ready solution and so I started to experiment.

The "run command on source startup" was the first thing I did, the 
intention of that was to ease the startup of a low-bitrate reencoded slave 
stream. They do this by connecting a client (on the server) that feeds the 
high-bitate stream into sox and then on into another mount.

Whenever a broadcaster disconnected, not only would all clients be dropped, 
but also this slave stream would stop. A way was needed to start it again 
when the next broadcaster got online and I chose this route. The 
run-on-connect command would start up this pipeline again in this case.

Then I was annoyed with listeners having to reconnect everytime the 
broadcaster changed. I started looking into configuring a fallback source 
and the first thing that bit me was the double-free bug.

These are among the hardest to fix, so I was forced to read and understand 
a lot of code while tracking it down. After I found it, I had a pretty good 
understanding of how icecast works.

Now my tests with fallback sources turned up a few shortcomings:

* clients cannot connect when the primary stream is down
* clients will listen to the fallback forever even when the primary is 
active again

My next idea was to use the command features to stop the fallback stream 
when the primary connects and make each the fallback of the other. But, 
something was needed to start the fallback again. So, why not let it's own 
disconnection make it start up again? The cmd-on-disconnect was born.

Then I thought "This works but it's not 100% reliable and it's not elegant."

Also it did not address the client connection problem while there wa no 
main stream.

Then I wrote the remainder of the patch. It worked very well and I thought 
"Now, what about this command stuff. Do I still need it?" and I decided to 
leave that in for submission becuse it can still be used to run a script to 
start the low-bitrate stream or check on the fallback and such.

Then I made some little changes to the original patch to allow 
daisy-chaining fallback sources. The primary souce would be used by various 
broadcasters to send their programming, it's fallback would be a script 
driven automatic playlist and it's fallback would be a jingle loop.

This way, there is programming if a broadcaster failed to connect and the 
interstices between that "emergency programming" from scripts would be 
filled by jingles.

In no case would clients get disconnected anymore.

The obvious pitfall and it's non-obvious solution is that, on stream 
connect, I appear to steal the clients from it's fallback.

Because of the way fallback streams are found, clients are _not_ stolen 
from a stream's fallback, but in fact are stolen from the first _active_ 
fallback. This is an important distinction because it makes it unnecessary 
to walk the fallback chain on source connection, as one may think is needed 
to collect all fallbacks' clients. Because of the way I implemented it, in 
a fallback chain, only the topmost source will _ever_ have clients, so only 
the topmost fallback needs to have it's clients stolen.
When a lower level source connects below a higher level one, by definition 
none of it's fallbacks can have active clients, so nothing needs to be done.

Through all of this the run command thing has become an afterthought, 
something to keep only because it's there. The uses for it I have left over 
could just as well be covered by a cron job.

If, as Mike suggested, the implementation is problematic, it may as well be 
removed with no great loss.

<p>I hope this sheds some light on things.

Best regards,

Melanie
--- >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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.