search for: kh17

...e, solid as a rock (no crashes) and running 100's of streams and 1000's of listeners, but in order to support authentication and have easier configuration I want to start using the url authentication (esp. the stream_auth) and mount-name wildcards that are supported by icecast-2.3.2-kh17. I am unsure about the stability of icecast-2.3.2-kh17 when using url authentication for both stream and listener authentication. What are the major differences between icecast-2.3.2 and the kh17 branch and can you say anything about the stability of icecast-2.3.2-kh17 in production use?...

...eentrant() return values must be freed, so probably > not a libxml problem. > > The Debian Testing Icecast source (2.3.2-4) does seem to have a case > where they are not freed: a do-while loop in stats.c:stats_get_xml() can > leak when breaking early. This code is not present in -kh17 that I'm > using and all xmlEncodeEntitiesReentrant() calls are fine there. I'm co-maintaining the Debian package. I have no time to test it myself right now, but I'd be interested to have your feedback and fix the issue if you find it. Romain

On Wed, Oct 21, 2009 at 5:53 PM, Karl Heyes <karl at xiph.org> wrote: >> I'm seeing quite a few wakeups/sec in icecast2 2.3.2 on Debian Testing. >> In fact, whether icecast is doing anything or not, powertop reports 44.3 >> wakeups per second. This is pretty big number, on my laptop it means >> icecast alone is responsible for every third wakeup on idle. > >

...test it. As a matter of fact I don't even have a > build environment (or time) available here, this is why I didn't send a > patch. > > But since you asked, attached are the missing frees for icecast2_2.3.2-4 > in a totally untested drive-by-patching manner. Like I said the -kh17 I > also happened to have did not have this specific code at all and the > xmlEncodeEntitiesReentrant() calls were all fine. The patch is fine, both kh and the trunk code use different code so those should not have this problem but feel free to report any issues like this. karl.

...alues must be freed, so probably >> not a libxml problem. >> >> The Debian Testing Icecast source (2.3.2-4) does seem to have a case >> where they are not freed: a do-while loop in stats.c:stats_get_xml() can >> leak when breaking early. This code is not present in -kh17 that I'm >> using and all xmlEncodeEntitiesReentrant() calls are fine there. > > I'm co-maintaining the Debian package. I have no time to test it myself right > now, but I'd be interested to have your feedback and fix the issue if you find > it. I'm not a icec...

On 09/12/2009 16:59, Romain Beauxis wrote: > Hi ! > > Le mardi 8 d?cembre 2009 19:59:23, Karl Heyes a ?crit : >>> But since you asked, attached are the missing frees for icecast2_2.3.2-4 >>> in a totally untested drive-by-patching manner. Like I said the -kh17 I >>> also happened to have did not have this specific code at all and the >>> xmlEncodeEntitiesReentrant() calls were all fine. >> The patch is fine, both kh and the trunk code use different code so >> those should not have this problem but feel free to report any is...

Hi, I've been noticing a huge memory usage on Icecast 2.3.2 on multiple debian instances. They are using like 100 MB after a day and going on until they hit like 1 GB.. So I ran one in valgrind, and killed it after ~24h, here is the output: ==30481== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 38 from 3) ==30481== malloc/free: in use at exit: 44,448,584 bytes in 44,470 blocks.

Hello there, Is there any way to have authentification on a db / ldap about sources and password instead of having one static entry in icecast.xml ? Any idea ? hacks ? patches ? Thanks /Xavier

...2009 16:59, Romain Beauxis wrote: > > Hi ! > > > > Le mardi 8 d?cembre 2009 19:59:23, Karl Heyes a ?crit : > >>> But since you asked, attached are the missing frees for icecast2_2.3.2-4 > >>> in a totally untested drive-by-patching manner. Like I said the -kh17 I > >>> also happened to have did not have this specific code at all and the > >>> xmlEncodeEntitiesReentrant() calls were all fine. > >> The patch is fine, both kh and the trunk code use different code so > >> those should not have this problem but feel fr...

> What I did notice is that the date field is not first, even though it's > date ordered. I personally didn't like that, so I just moved the date > field. opinions ? Please don't change the ordering of the fields. It's quite deliberately ordered for compatibility with the Apache Common Log Format. (hmm... or is it the Combined Log Format? I forget...) Mike --- >8