On Mon, 12 Apr 2005, Karl Heyes wrote:> My current work is on > http://mediacast1.com/~karl/testing/icecast-2.2-kh3pre.tar.gzBugs: Relays ignore the hidden flag HUPing icecast puts icecast in a strange state where it doesn't actually take account of the conf changes, and also won't terminate on a TERM and needs a KILL - but it does still "work" otherwise. How is fallback to file actually meant to work ? I notice you've got fallback-when-full, I would like to fallback (on full) to a URL - 302 style - but on a per mount basis rather than setting up a whole master/slave relationship.
On Tue, 2005-04-12 at 14:44, gARetH baBB wrote:> On Mon, 12 Apr 2005, Karl Heyes wrote: > > > My current work is on > > http://mediacast1.com/~karl/testing/icecast-2.2-kh3pre.tar.gz > Bugs:2 other bugs came up, one was relating to excessive memory usage when using theora and server full messages. Both are fixed now> Relays ignore the hidden flagthey work here, although the hidden attribute is associated with a mount, not a relay.> HUPing icecast puts icecast in a strange state where it doesn't > actually take account of the conf changes, and also won't terminate on a > TERM and needs a KILL - but it does still "work" otherwise.this is fixed now, turned out to be a read lock not releasing.> How is fallback to file actually meant to work ?just state a filename within webroot. The server creates a source thread so that it interacts with the existing fallback mechanism. No timing goes on with the data stream, and usual rules for fallbacks apply, ie same format and same parameters.> I notice you've got fallback-when-full, I would like to fallback (on full) > to a URL - 302 style - but on a per mount basis rather than setting up a > whole master/slave relationship.Well 302 will only work on initial connection not after streaming has occurred. I've still to work on the existing mechanism to see which is best but that could work. karl.
On Wed, 13 Apr 2005, Karl Heyes wrote: [please don't email and post - well, I say post, but the xiph list server doesn't actually send *me* the *list* post at all]> they work here, although the hidden attribute is associated with a > mount, not a relay.My mistake.> just state a filename within webroot. The server creates a source threadNo, still not getting this. <mount> <mount-name>/fish.mp3</mount-name> <fallback-mount>click.wav.mp3</fallback-mount> <fallback-override>1</fallback-override> </mount> causes not only fish.mp3 to not appear in status, but it doesn't fallback to the file either. Putting a real fallback mountpoint in works.
On Wed, 14 Apr 2005, gARetH baBB wrote:> <mount> > <mount-name>/fish.mp3</mount-name> > <fallback-mount>click.wav.mp3</fallback-mount> > <fallback-override>1</fallback-override> > </mount> > > causes not only fish.mp3 to not appear in status, but it doesn't > fallback to the file either.D-oh, I get it now - I was presuming you were being literal when you said "put a filename" (and that a fallback without a leading / was detected and treated specifically as a file) and now understand it does still have to be preceded by /.
Karl Heyes wrote:> On Tue, 2005-04-12 at 14:44, gARetH baBB wrote: > >>How is fallback to file actually meant to work ? > > > just state a filename within webroot. The server creates a source thread > so that it interacts with the existing fallback mechanism. No timing > goes on with the data stream, and usual rules for fallbacks apply, ie > same format and same parameters. >a word of warning: the fallback files will be served untimed, i.e. as fast as the receiving end can process them. if it's a relay, then this will eat up your entire bandwidth. i've seen loads of 30+ mbit/s with just two relays. if all your clients are actual players, you will be fine, but even one wget will really warm your uplink :)