Have now set the log to level 4 and viewed the output when the stream stops/starts. Can't see any errors though. I'm getting: source/source_move_clients passing 1 listeners to "/fallback.mp3" on stream stop and: source/source_move_clients passing 1 listeners to "/studio" when the stream starts again, so looks like it's working. Could it be the client at fault? Also, I did notice that sometimes (very occasionally) it will actually work but takes about 3 to 4 minutes to action. I tried the test again but it doesn't work every time only works occasionally. Any ideas? I can show you the logs if you like. Thanks very much for the help it's appreciated, Andy ----- Original Message ----- From: "Karl Heyes" <karl@xiph.org> To: "paranoid" <paranoid@dds.nl> Cc: <icecast@xiph.org> Sent: Tuesday, January 17, 2006 8:41 PM Subject: Re: [Icecast] [Icecast-dev] metadata fallback mounts> paranoid wrote: >> >> Hi all, > >> First of all thanks again for icecast2. It keeps surprising me how easy >> and stable it is to use! > > we do try to make it easy, but there are people who still have trouble :) > >> Now this /play.ogg has the fallback /live.ogg and /live.ogg has the >> fallback /playlist.ogg. In the config file I added metadata for the >> /play.ogg mount point that looks like this: >> >> <mount> >> <mount-name>/play.ogg</mount-name> >> <stream-name>Beathead Broadcasts</stream-name> >> <stream-description>Homebrew Broadcasts for Hip >> Beatheads</stream-description> >> <stream-url>www.beathead.net</stream-url> >> <genre>beats</genre> >> <fallback-mount>/live.ogg</fallback-mount> >> <fallback-override>1</fallback-override> >> <fallback-when-full>1</fallback-when-full> >> <hidden>0</hidden> >> <no-yp>0</no-yp> >> </mount> >> >> Unfortunately, when I look at the /play.ogg metadata in status.xsl, it is >> al empty. >> >> Do I use the wrong metadata tags in the config or is this normal >> behaviour for a non-connected mount which only serves as main entry mount >> point? > > That info is really for the YP servers currently, initially for cases such > as inactive on-demand relays. You may want to have /play.ogg as a local > relay of /playlist.ogg with /live.ogg configured for fallback/override. > > karl. > > _______________________________________________ > Icecast mailing list > Icecast@xiph.org > http://lists.xiph.org/mailman/listinfo/icecast
Andy Woolley wrote:> Have now set the log to level 4 and viewed the output when the stream > stops/starts. > > Can't see any errors though. I'm getting: > > source/source_move_clients passing 1 listeners to "/fallback.mp3" > > on stream stop and: > > source/source_move_clients passing 1 listeners to "/studio" > > when the stream starts again, so looks like it's working. > > Could it be the client at fault? > > Also, I did notice that sometimes (very occasionally) it will actually > work but takes about 3 to 4 minutes to action. I tried the test again > but it doesn't work every time only works occasionally.from the description, it sounds like it is doing what it's supposed to be doing, but the listening client is buffering a large amount of the sent stream data. The player will have a buffer, verify what setting that is at and what the stream stream bitrate is. karl.
karl wrote:> from the description, it sounds like it is doing what it's supposed to be > doing, but the listening client is buffering a large amount of the sent > stream data. The player will have a buffer, verify what setting that is > at and what the stream stream bitrate is.Seems this is the answer, it's working but there is a 4-5 minute delay caused by a buffer once the fallback returns to the stream This then puts the stream 4-5 minutes behind when it finally starts up. Is there anything server side that I can change to make the time gap shorter? Regards, Andy ----- Original Message ----- From: "Karl Heyes" <karl@xiph.org> To: "Andy Woolley" <andy@milonic.com> Cc: <icecast@xiph.org> Sent: Tuesday, January 17, 2006 11:11 PM Subject: Re: [Icecast] [Icecast-dev] metadata fallback mounts> Andy Woolley wrote: >> Have now set the log to level 4 and viewed the output when the stream >> stops/starts. >> >> Can't see any errors though. I'm getting: >> >> source/source_move_clients passing 1 listeners to "/fallback.mp3" >> >> on stream stop and: >> >> source/source_move_clients passing 1 listeners to "/studio" >> >> when the stream starts again, so looks like it's working. >> >> Could it be the client at fault? >> >> Also, I did notice that sometimes (very occasionally) it will actually >> work but takes about 3 to 4 minutes to action. I tried the test again but >> it doesn't work every time only works occasionally. > > from the description, it sounds like it is doing what it's supposed to be > doing, but the listening client is buffering a large amount of the sent > stream data. The player will have a buffer, verify what setting that is > at and what the stream stream bitrate is. > > karl.