Icecast Streaming Media Server

[gouranga]

compiled your latest tarball, seams to be fine, but after 2 hours it felt down after

[karlH]

ok thanks, I'll check that code in the subtree next time. You will have to explain what you mean by any other issue.

karl.

[karlH]

kh18 is now up. 2 possible areas for memory corruption were cleared up. some people have experienced larger bandwidth usage for vorbis streams from certain source clients, this should now be resolved as well.

karl.

[gouranga]

hey karlH!
kh18 is brilliant.

but one bug happens: after client got disconnected from source, it disappears from source array in xsl. after some client disconnects from any other mount — previous missed gets back again, but the last dissapears) that happens to on-demand mounts only.

each my

[karlH]

Happy new year, and just to bring in the new year, I've uploaded a kh19. A number of people have given me feedback on various aspects and things seem to be settled now. This has a small number of bug fixes in (internal stuff) so it is recommended, I have however added per-mount access logs if that is of interest.

tarball and win32 build at the website.

karl.

[LBB]

Happy New Year too
and thanks for this new release.

But I've this error message during 'make' of icecast-2.3.2-kh19 :

[karlH]

ok, I've uploaded a kh19b. For those running with listener_remove auth url option, this is to remove a possible race crash. I've also added a missing include for your build failure (kh18 didn't have the per-mount access log option).

http://www.icecast.pwp.blueyonder.co.uk/icecast-2.3.2-kh19b.tar.gz

let me know if that builds for you and I'll change the link over.

karl.

[LBB]

It works perfect
many thanks Karl !

[audiorapture]

kh19b:

[2010-01-12 07:32:57] WARN cfgfile/parse_xml_tags unknown element "threadpool" parsing "limits"
[2010-01-12 07:32:57] WARN cfgfile/parse_xml_tags unknown element "burst-on-connect" parsing "limits"

Here is the limits section from icecast.xml:
<limits>
<clients>500</clients>
<sources>9</sources>
<threadpool>10</threadpool>
<queue-size>524288</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>5</source-timeout>
<!-- If enabled, this will provide a burst of data when a client
first connects, thereby significantly reducing the startup
time for listeners that do substantial buffering. However,
it also significantly increases latency between the source
client and listening client. For low-latency setups, you
might want to disable this. -->
<burst-on-connect>1</burst-on-connect>
<!-- same as burst-on-connect, but this allows for being more
specific on how much to burst. Most people won't need to
change from the default 64k. Applies to all mountpoints -->
<burst-size>65535</burst-size>
</limits>

[karlH]

that is expected, both those tags are not used which is why a warning is flagged, just in case of a typo.

karl.

[epe]

hi karl
yesterday I compiled the latest kh version, and at random, after a few hours running, I got a:

[karlH]

I have a kh19f at my site if you want to try it out. The easiest way to provide useful info (on linux at least) is build with make debug and use

catchsegv .../icecast ....

send back the stack dump shown on crash, along with logs/xml so I can see what's going on.

karl.

[karlH]

kh20 is up. This contains fixes only so it is a recommended update. Many thanks to the various people providing bug reports, and providing testing for platforms such as win32 and FreeBSD.

karl.

[karlH]

kh21 is up. This is a bugfix release so a recommended update. This fixes a worker stalling bug which could occur if you have source clients exiting frequently. Relay handling has a NULL pointer fix which could appear in slave setups or if you manually add/remove relays.

karl.

[karlH]

*sigh, kh21a has an important memory corruption fix in. It only occurs if you use multiple workers and have a particular load of new listeners connecting but it's there and now fixed. The bug was introduced in kh20 to resolve a locking issue.

karl.