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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Thomas B. Ruecker, DM8TBR
2004-Aug-06 14:57 UTC
[icecast-dev] Re: Fwd: More fallback handling
Hi Melanie, Hi all, I'd just like to mention: This is exactly the functionality that I was missing in Icecast. I think it's one of the most important things when running a small internet radio not to disconnect the listeners on any event! (in most cases only few of them reconnect) :-( It would be really nice to see this feature in the official Icecast source. Thanks for the work Melanie! Thomas --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Hello DM8TBR, Wednesday, November 5, 2003, 12:46:27 PM, you wrote:> Hi Melanie, > Hi all,> I'd just like to mention: This is exactly the functionality that I was missing in Icecast.> I think it's one of the most important things when running a > small internet radio not to disconnect the listeners on any event! > (in most cases only few of them reconnect) :-(> It would be really nice to see this feature in the official Icecast source. > Thanks for the work Melanie!> ThomasHi all, I agree with you, Thomas. I'm forced to do some silly external mountpoint connection/disconnection checking. I'd really appreciate that feature. Thanks all, Stepan Broz, aka Kato <p>--- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
At 08:34 AM 11/5/2003 +0100, you wrote:>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. >first off I'd like to say that we really do appreciate the work you did, and we encourage (very much so) contributions from other developers..this is the kind of thing that helps icecast tremendously... that being said, here are my thoughts on this patch... I'm not a big fan of the "run command" features. I believe that adds a bit too much complexity (not to mention the fact that this approach won't work in win32) for the benefit it provides. The fallback enhancements though I think are really very good and should be included in icecast. This is a bit of a complicated scenario so it might take a bit to get it integrated and tested, but definately worthwhile. oddsock <p>--- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Hi, I have observed a problem when streaming with ices2. When only silence is transmitted, like pauses in an interview, the bitrate drops to 0. This happens even when a minimum bitrate is set. Now, assume there is a half block of audio ready. Now the level drops to silence, or near silence, possibly because the person is thinking about an answer for a while. This will cause the partial block to not be transmitted in time for the client to produce continuos audio. Also, the client can, if this happens more often, incur some very serious lag over time. What needs to be done, IMHO, is to guarantee that data is sent at least as fast as the playback of the data will take. So, if there is silence, smaller blocks must be sent, because a length of music and an equal length of silence will be encoded in a different number of bytes. Each block of data being collected, waiting for transmission, neds a deadline attached to it which is the time between the sending of the last block and the time it would finish playing. So, if a block is sent that encodes 2 seconds of audio, the next block must be sent no more than 2 seconds later. Even if it's only the few bytes needed to tell the client to play another 2 seconds of silence. I haven't read the code, but it appears that blocks are sent when a certain byte count is reached. This is fine for continuous audio, but if there is silence involved, it's just not enough. A functioning minimum bitrate would also solve this problem, at the cost of bandwidth, but that's not available either. The minimum bitrate parameter is seemingly ignored, even though the ices2 startup messges do print it out, meaning it's recognized from the config file. This becomes a major annoyance when anything other than continuous music is sent, even with normal talk, lag time can build up and bits of disjoint audio are heard at the beginning of a sentence. This is probably the tail of the last sentence, encoded and buffered, but not sent out until there is more audio to send. 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.