At 08:09 AM 11/7/01 -0500, you wrote:>Hi everyone: I am running a couple of ices2 streams one with a fairly >small playlist and one with a play list which is currently about 1000 >pieces. The 1000 piece stream appears to have a bad memory leak. The >streamer dies about every 16 to 20 hours with a process out of memory >error. Has anyone else seen this problem or have any suggestions? >The stream with the smaller play list appears to not have any problems >at all.I've committed something which might (but I doubt it) be the cause of this - it's worth a try, at least, I guess. Is the playlist being reloaded very frequently? (playlist reloads get logged at level INFO) - even if it were, that shouldn't leak enough to be noticable in under a day. If not, then the length of the playlist should be irrelevent - unless there's a bad entry, or an entry pointing to a bad file, that it's choking on. You're not reencoding or anything? The reencoding code (or just encoding, though that's less likely) is by far the most likely culprit for major leaks. If you are, can you turn this off for a day or so to ensure that this is the problem? I saw something like this a couple of weeks ago locally - I'd left things running (xmms, icecast2, ices2) overnight, and when I came home the following day the kernel had killed off all three - I didn't have time to look into things then. Maybe this was the same problem? I don't know what setup I was running at the time.> >I am using ices2 and libshout2 out of cvs. The ogg encoding is >44100hz stereo encoded at oggenc's default compression. The stream is >feeding two streams, one at 128 bits and the other at 64. I also have >a hunch the pieces are occasionally getting clipped off before their >end but I'm not a hundred percent sure because it does not always >happen. Fairly rarely actually.I haven't noticed this, but I haven't done extensive testing lately (an automated test-suite is really hard to construct for this sort of thing, since a lot of the things I'd want to test for are VERY highly timing dependent. Still, it'd be nice to have...) If you can confirm that it DOES happen, I'll try to look deeper. Michael --- >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.
Okay, I am re-encoding the 64bps stream from the 128 encoded files in the 1000 play list. I'll try shutting that down and see if that helps before I update cvs. Some days the play list gets reloaded a number of times because I'm adding new material. Other days it does not. I haven't added anything for the past 4 or 5 days though and I'm still seeing the problem. I'll try shutting down the 64 bps re-encode stream and watch for a day or so and get back to you. Kirk -- Kirk Reiser The Computer Braille Facility e-mail: kirk@braille.uwo.ca University of Western Ontario phone: (519) 661-3061 --- >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.
At 06:36 PM 11/7/01 -0500, you wrote:>Okay, I am re-encoding the 64bps stream from the 128 encoded files in >the 1000 play list. I'll try shutting that down and see if that helps >before I update cvs. Some days the play list gets reloaded a number >of times because I'm adding new material. Other days it does not. I >haven't added anything for the past 4 or 5 days though and I'm still >seeing the problem. > >I'll try shutting down the 64 bps re-encode stream and watch for a day >or so and get back to you.Having looked a little closer at potential causes for this problem, it looks like my bugfix yesterday (which I thought at the time was inconsequential and unlikely to ever have any important effect) is actually relevent here - it could well have caused BIG memory leaks in certain cases when reencoding (cases that my normal tests happened not to catch, I guess). I think things should be ok now, and I'm running a full reencoder test locally at the moment. Michael --- >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.
At 06:36 PM 11/7/01 -0500, you wrote:>Okay, I am re-encoding the 64bps stream from the 128 encoded files in >the 1000 play list. I'll try shutting that down and see if that helps >before I update cvs. Some days the play list gets reloaded a number >of times because I'm adding new material. Other days it does not. I >haven't added anything for the past 4 or 5 days though and I'm still >seeing the problem.I just found another memory leak, this one in the playlist-reloading code. This one wouldn't be huge (unlike the reencoder leak), but it might exacerbate the problem. It's fixed now, in cvs. Also, the reencoder code is now MUCH more tolerant of bad input. So is the rest of ices2. Now it won't collapse in a heap if you feed it bad files. Michael --- >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.