Thanks for offering to help, Karl. Config - I thought my email was long even without the config files so I didn't include them! They are normal random playlist configs. What aspects are you looking for? CPU - vmstat 1 gives consistant CPU readings of around 2,1,97 for us,sy,id respectively when no one is listening to the streams. There's hardly any change when a client starts listening. I've taken a quick look at the code and seen the point where the log entry is written, I was hoping that someone with better (ie some) knowledge of the code would point me to the problem area rather than me having to wade through it all myself. I have made unusual encode settings, but it still used a standard oggenc build. I've listened to the streams with both xmplay and winamp now to see if the stream dropping was a winamp only issue and found that xmplay also drops the 25kbs one, but not at the same point that winamp does. The server also doesn't warn it booted the client so I'm guessing buffer issues for the stream problem. What the "extended sleep" thing is beats me at the moment though. It's a 22050khz encode, but there is another one with out the sleep issues. I now have a log file of 11MB after a day and a bit, it's not useful. Thanks again for trying to help me out, Mark. --- Karl Heyes <karl@pts.tele2.co.uk> helpfully wrote:> Notice how the ms count increases. What's the config > like and is you CPU swamped. use vmstat 1 to see CPU > usage. > > karl.__________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- >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.
>What the "extended sleep" thing is beats me at the >moment though. It's a 22050khz encode, but there is >another one with out the sleep issues. I now have a >log file of 11MB after a day and a bit, it's not >useful.<p>This basically means "something really bad has gone wrong, we're trying to recover". Depending on the cause of the problem, the recovery may or may not be successful. That message appears when the timing code encounters a situation which it never should (but can if there are clock discontinuities or insufficient cpu). It might also be possible to trigger it with some (broken) input files - does this problem happen only with some files? Michael <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.
On Mon, 2 Dec 2002, SwiftBiscuit wrote:> What the "extended sleep" thing is beats me at the > moment though. It's a 22050khz encode, but there is > another one with out the sleep issues.hmmmm. so is there a difference between the one that works and the one that doesn't? Bitrate, maybe? Geoff. <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.
I've just finished a little encoding set and the following happened: 22Khz resampled, q-0.4 encode = ~38kbs = one error at the beginning only. 22Khz resampled, q-0.5 encode = ~37kbs = 6 to 7 sleep errors in the first second or so, nothing after that. 22Khz resampled, q-0.6 encode = ~35kbs = 14 to 15 sleep errors then nothing. 22Khz resampled, q-0.8 encode = ~33kbs = Many sleep errors. --- Geoff Shang <gshang@uq.net.au> wrote:> hmmmm. so is there a difference between the one > that works and the one > that doesn't? Bitrate, maybe? > Geoff.__________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- >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.
On 2002.12.02 13:21 Michael Smith wrote:> This basically means "something really bad has gone wrong, > we're trying to recover". Depending on the cause of the > problem, the recovery may or may not be successful.This looks like it needs a bit more work wrt the playlist read code. The ogg_sync_pageout will be emitting pages containing around 22k samples, and there's only 22k samples in a second at that samplerate so that will trigger the 1 sec sleep check. I suspect we need to flush a page which has some basis on the samplerate or time, but I don't think there's a function for that. hmmmm....how big can an ogg page get? And what about even lower samplerates like 11025? <p>> That message appears when the timing code encounters> a situation which it never should (but can if there are > clock discontinuities or insufficient cpu). It might > also be possible to trigger it with some (broken) input > files - does this problem happen only with some files?I suspect it will only happen on 22ksamplerate or less files through the playlist as pcm only read 8192 samples. The quick hack is to increase the trigger in _sleep from 1000 to say something like 5000. 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.