search for: kh3pre

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: 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...

Karl Heyes wrote: > A container from nullsoft hm, I learn something new every day :) >>so when the source client logs in, it lies to icecast, saying it's an >>mp3 stream? (as icecast won't accept anything else, but mp3 or ogg >>vorbis...) > > no, a source client identifies itself with a mime-type. MP3 being the > default handler. Being the default handler

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 flag they work here, although the hidden attribute is associated with a mount, not a relay. > HUPing icecast puts...

OK, so let me check I understand how the timing must work: 0) New user joins the jukebox and wants to start listening to music. Jukebox app selects a mountpoint name, user ID and password 1) Modify the icecast.conf file with the new mountpoint 2) Send HUP to icecast 3) Set up username:password for new stream 4) Create new stream's ices.conf file 5) Spawn new instance of ices to stream