On 2002.11.12 11:52 Leo Currie wrote:> Karl Heyes wrote:> Just came in this morning and it is sitting there using 98.5% cpu and > 47.6% memory. So yes - memory usage goes up as well. My playlist is > 'clean' of mp3's now, so it's something else..Yes, it's a case of normal running is fine, but on some network error one or more threads go into busy loop not emptying it's queue.> Strange thing though - I'm using 2 instances in my config file (2 > different bitrates, same playlist), and it's only one mountpoint that has > gone - there other is still running fine.That can happen, usually there is some fluctuation and depending on the tollerance that can stuff the just one or even all the streams. A lower bandwidth stream won't sent as much data for instance.>> It's a very nasty bug, but only occurs if the connection to icecast >> terminates unexpectedly, eg ctrl-C icecast or if the time on the ices >> machine changes significantly. Try the attached patches if that's >> the issue. > > Well, Icecast is still running, and my clock is on time - how significant > a change do you mean?Well assuming a pure clock change, a change of 10 secs could cause an extended sleep period in which icecast could drop the connection. In this case increasing the source-timeout is not the right solution as a 10 second gap in audio streaming is really bad! A simple log message could help track those type of problems. If the sleep is over say 2 seconds then show warning. hmmm patch brewing!!.> Thanks for the help - I'll try those patches anyway!The send_raw one fixes the busy loop problem, and the ices patch prevents excessive memory usage and few seg vaults that had shown up. karl. --- >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.
Karl Heyes wrote:> Well assuming a pure clock change, a change of 10 secs could cause an > extended sleep period in which icecast could drop the connection. In > this case increasing the source-timeout is not the right solution as > a 10 second gap in audio streaming is really bad! A simple log message > could help track those type of problems. If the > sleep is over say 2 seconds then show warning. hmmm patch brewing!!.Hmm. Well, it ran fine again for 14+ hours, but then - blammo. I got nothing from my ices log (stupid stupid me had loglevel set to only 3..) but icecast said: "Disconnecting source due to socket read error: Broken pipe" I have put debug logging on, so I'll wait and see.> > The send_raw one fixes the busy loop problem, and the ices patch > prevents excessive memory usage and few seg vaults that had shown up.<p>Sorry this is such a newbie question but i'm not sure if I applied the patch correctly: Suppose my current directory is where i put the files from cvs, so i have a sub-directory called ices, and one called libshout. I also have those patches in this directory. Do i just do: 'patch -p4 <send_raw.diff' ? Thanks. Leo <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.
Karl Heyes wrote:> Having mp3's in the playlist won't work well:). It's not supposed to stop > ices though, same for non-existent files. I'll have to check that. The > swallow all my CPU sounds like the send_raw bug. Does it also show an > increased memory usage as well?<p>Just came in this morning and it is sitting there using 98.5% cpu and 47.6% memory. So yes - memory usage goes up as well. My playlist is 'clean' of mp3's now, so it's something else.. Strange thing though - I'm using 2 instances in my config file (2 different bitrates, same playlist), and it's only one mountpoint that has gone - there other is still running fine.> It's a very nasty bug, but only occurs if the connection to icecast > terminates unexpectedly, eg ctrl-C icecast or if the time on the ices > machine changes significantly. Try the attached patches if that's > the issue.Well, Icecast is still running, and my clock is on time - how significant a change do you mean? Thanks for the help - I'll try those patches anyway! Leo --- >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.