I am having a problem with darkice and i was hoping that you could help me.
i'm running freebsd 4.2. i had icecast-1.3.7 and darkice-0.7. icecast was
+building to 100% cpu so i up'd it to 1.3.11. icecast now runs at a
reasonable
+cpu but i'm getting the following error when i try to start darkice:
DarkIce: DarkIce.cpp:572: can't open connector [0]
any help that you can give me is greatly appreciated. if there is anything i
+can provide you please let me know. thanks.
chris
--
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (OpenBSD)
Comment: For info see http://www.gnupg.org
key available at http://redlight.homeip.net/chollow.publickey
-----END PGP PUBLIC KEY BLOCK-----
--- >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 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.
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 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. Any suggestions would certainly be appreciated. 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.