Karl, It would certainly be a useful feature for me and I guess others. The current solution with ezstream works but listeners all end up at the same (current) point in the mp3 file. With the mp3 file as a fallback each individual listener would want to start hearing it from the start. This might be more difficult to implement with the single-q that is in the current trunk code, I don't know. About the status of the svn 2.1 trunk code. What is the status? I guess it's not a stable release? Or is it stable enough to use it in a production system. If it is stable/mature enough I could start using it (with its extra features and bugfixes) in my production system. Any thoughts? Cheers, KJ> > Van: Karl Heyes <karl@xiph.org> > Aan: Klaas Jan Wierenga <k.j.wierenga@home.nl> > CC: icecast <icecast@xiph.org> > Datum: di 7 sep 04, 16:48 > Onderwerp: Re: Antw: Re: [Icecast] fallback to static mp3 file? > > On Tue, 2004-09-07 at 15:39, Klaas Jan Wierenga wrote: > > Hi Geoff, > > > > Thanks, that sounds like a good idea. I've just tried it and of course it works. Then I discovered that when the original source is not connected icecast doesn't fall through to the fallback mount. Is this a known problem? > > yes it is, for the v2.0.1 release. The trunk code (ie for 2.1) has a > more complete fallback support. > > wrt your original query, I'm not aware of any plans to add such a > feature but I suspect it can be added without too much grief, whether it > will before 2.1 is released is another matter. > > karl. > > >
On Tue, 2004-09-07 at 17:54, Klaas Jan Wierenga wrote:> Karl, > > It would certainly be a useful feature for me and I guess others. The > current solution with ezstream works but listeners all end up at the > same (current) point in the mp3 file. With the mp3 file as a fallback > each individual listener would want to start hearing it from the > start. This might be more difficult to implement with the single-q > that is in the current trunk code, I don't know.The single-q changes would not affect anything like this, this would be purely a client handling change. Don't forget icecast does have file serving capabilities so it would be just a matter of doing internal changes to handle source to file serving client migration and vice versa. I need to look at the specifics to an idea of the extent of the changes.> About the status of the svn 2.1 trunk code. What is the status? I > guess it's not a stable release? Or is it stable enough to use it in > a production system. If it is stable/mature enough I could start using > it (with its extra features and bugfixes) in my production system. Any > thoughts?Whether it is stable enough is hard to say, as the only measure for that is heavy usage. From the feedback I've had and the lack of faults reported I would say it is certainly stable enough for most is not all users :) There are still some known issues to resolve for trunk but those are not easy to trigger and in fact are not really stability issues. karl.
Karl Heyes wrote:> Don't forget icecast does have file > serving capabilities so it would be just a matter of doing internal > changes to handle source to file serving client migration and vice > versa. I need to look at the specifics to an idea of the extent of the > changes.What would be cool is an initial static file being sent before joinging a life stream, such as shoutcast can do. For static situations, a static file can be put in the calling M3U or PLS file, but I'm thinking about the ability to do this for fallbacks. We have two situations where this would be useful. First, at times we haave an automaation system which uses Oddsock's Song Requester plugin to take requests when no-one is on the air. It would be great if, when a stream fell back to this stream on its own mountpoint, the listener could be told that this was the case and to go to our website to make requests. New listeners would also benefit in this situation. The other situation is that we have a backup loop that kicks in when no-one is on. We could have a loop of files that cycles, and a message at the front that tells people of the break in transmission and thata programming will resume shortly. This means that anyone listening doesn't haave to hear the same loop from the beginning all the time, but they can be told up front what the situation is so they know.> There are still some known issues to resolve for trunk but those are not > easy to trigger and in fact are not really stability issues.So how far away are we from a release? I'm keen to deploy this code, but I'm a bit reluctant to put development code up, though I could do this I guess as it is pretty stable as you say. The other question I have from a friend is, if it's going to be awhile till the next release, are there any windows binaries of the development code? Geoff.