this is probably caused by the lack of buffering in icecast2. Their relay client may be doing some buffering in itself, and if it's expecting for there to be buffering on the server side as well, it might exhibit a behavior you are seeing....(that also is a difference between iceast1 and icecast2 - no server-side buffering in icecast2 and there was in icecast1)... fwiw, I am trying to implement server side stream buffering right now, but it's not quite working as yet....This may address your problem, and it certainly will address the problems of clients having to do a serious amount of apparent buffering before listening to a stream. oddsock At 10:24 PM 5/14/2003 -0600, you wrote:>Hi All, > >I attempted to switch my MP3 server from Icecast 1 to Icecast 2 today. I >run a Live365 station, Big Planet Radio, which simply relays my local >Icecast server. > >My Icecast 2 error.log file shows a lot of the following messages when the >Live365 server, Nanocaster 2.5.6, is connected to it: > > >[2003-05-14 22:09:15] DBUG format-mp3/format_mp3_write_buf_to_client >Client had recoverable error -1 > >[2003-05-14 22:09:15] DBUG format-mp3/format_mp3_write_buf_to_client >Client had recoverable error -1 > >[2003-05-14 22:09:35] DBUG format-mp3/format_mp3_write_buf_to_client >Client had recoverable error -1 > > > >I realize this may not be near enough information, but any idea what might >be going on here? When listening to the Live365 station, these errors are >apparently manifest by breaks in the audio while the Live365 Nanocaster >attempts to resynchronize or something. > > > >When using Icecast 1, Nanocaster stays connected for days on end without >any errors reported in error.log, and no breaks in audio. > > > >FWIW, the app streaming to Icecast is my own home-brew automation system >using Libshout 2. > > > >I'm a coder, so if anyone has ideas, I'd be happy to poke around a bit. > > > >Thanks for any help! > > > >marc > > > >--- >Keeping you entertained and informed -- Big Planet Radio ><http://www.bigplanetradio.com/>http://www.bigplanetradio.com ><p><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-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.
> behavior you are seeing....(that also is a difference between iceast1 and > icecast2 - no server-side buffering in icecast2 and there was in > icecast1)...What do you mean stream buffering? We never buffered in either version that I remember. If you fall behind, you get kicked. It's always been that way. jack. --- >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-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 All, I attempted to switch my MP3 server from Icecast 1 to Icecast 2 today. I run a Live365 station, Big Planet Radio, which simply relays my local Icecast server. My Icecast 2 error.log file shows a lot of the following messages when the Live365 server, Nanocaster 2.5.6, is connected to it: [2003-05-14 22:09:15] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error -1 [2003-05-14 22:09:15] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error -1 [2003-05-14 22:09:35] DBUG format-mp3/format_mp3_write_buf_to_client Client had recoverable error -1 <p><p>I realize this may not be near enough information, but any idea what might be going on here? When listening to the Live365 station, these errors are apparently manifest by breaks in the audio while the Live365 Nanocaster attempts to resynchronize or something. <p><p>When using Icecast 1, Nanocaster stays connected for days on end without any errors reported in error.log, and no breaks in audio. <p><p>FWIW, the app streaming to Icecast is my own home-brew automation system using Libshout 2. <p><p>I'm a coder, so if anyone has ideas, I'd be happy to poke around a bit. <p><p>Thanks for any help! <p><p>marc <p><p> --- Keeping you entertained and informed -- Big Planet Radio http://www.bigplanetradio.com <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.
Marc Mulcahy <marc@plbb.net> said:> Hi All, > > I attempted to switch my MP3 server from Icecast 1 to Icecast 2 today. I > run a Live365 station, Big Planet Radio, which simply relays my local > Icecast server. > > My Icecast 2 error.log file shows a lot of the following messages when the > Live365 server, Nanocaster 2.5.6, is connected to it: > > [2003-05-14 22:09:15] DBUG format-mp3/format_mp3_write_buf_to_client Client > had recoverable error -1 > > [2003-05-14 22:09:15] DBUG format-mp3/format_mp3_write_buf_to_client Client > had recoverable error -1 > > [2003-05-14 22:09:35] DBUG format-mp3/format_mp3_write_buf_to_client Client > had recoverable error -1 > > > > I realize this may not be near enough information, but any idea what might > be going on here? When listening to the Live365 station, these errors are > apparently manifest by breaks in the audio while the Live365 Nanocaster > attempts to resynchronize or something.This usually means that the client wasn't keeping up well enough. The most common reasons for that are a) network link too slow, or b) source client (you said you wrote your own, though libshout is meant to handle that part) is sending too fast. That debug message is also slightly wrong: format_mp3.c line 189 should use sock_error() rather than ret to print the actual error code. Not sure if that'll actually help you, though. Note that it _is_ a debug message, and icecast (unless there's a bug in the mp3 format handler? It's possible, that's not the best-tested of code, since it was largely written when I had no mp3 source client available at all) will NOT lose data because of it. It's a sign that something might be not-so-good, but shouldn't be a problem by itself. It's probably worth having a better look at format_mp3_write_buf_to_client (ooh. there's a clumsy function name! :-) if you're interested, there could be bugs there - are you using mp3 metadata? If so, that codepath is about an order of magnitude more complex, so there's more chance of subtle errors. Mike --- >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.