search for: deltasolut

Hi Guys, My first post here so hello to all :-)) Anyway, my question: Does anybody know if there is a tool out there that can process the icecast log files and return a graph of listener numbers over a set period? I'd like to be able to know when our most busiest time was. Thanks very much in advance, Andy

...ur device). Appreciate your comments. KJ p.s. Btw we're using a CBR stream as you might have guessed. -----Oorspronkelijk bericht----- Van: mlrsmith@gmail.com [mailto:mlrsmith@gmail.com]Namens Michael Smith Verzonden: woensdag 28 december 2005 17:14 Aan: Klaas Jan Wierenga CC: henri.zikken@deltasolutions.nl; icecast@xiph.org Onderwerp: Re: [Icecast] Use of TCP_CORK instead of TCP_NODELAY > > p.s. For an in depth analysis of TCP_CORK read Christiopher Baus' excelent > article: http://www.baus.net/on-tcp_cork Thanks for this pointer. I'd been meaning to reply on this thread, b...

> > p.s. For an in depth analysis of TCP_CORK read Christiopher Baus' excelent > article: http://www.baus.net/on-tcp_cork Thanks for this pointer. I'd been meaning to reply on this thread, but hadn't got around to it, primarily because I didn't really understand TCP_CORK (the linux manpage is, as usual, fairly unclear on what exactly it does). Now I understand! > >

We are using icecast as stream-relay for a true narrowcast solution we've developed. The idea behind the system is that each individual client gets it's own mountpoint. Basically we have an application that creates streams. Its written in c++ and uses libshout to handle connecting to icecast. Everything works fine, as long as we keep the number of mountpoints below 347. As soon as we

> As a streaming server, it's fairly crucial for icecast to > send out data with as low a delay as possible (many clients > don't care, but some do). That's why we use TCP_NODELAY - we > actually WANT to send out data as soon as we can. Nagle is inherently unsuited for streams. NODELAY was (imho) ment for connections for which Nagle isn't sufficient and CORK is not

A small update from my side.. i have updated both icecast and libshout to the nightly snapshot versions of icecast.org. Also, in the configfile i have raised the threadpool to 500 and all timeouts to 3000. This did help a bit. Right now i can get it up to 1020 inputstreams, however then it just stops accepting new connections. Is there a theoretical maximum to the number of mountpoints icecast

We're abusing icecast in a true narrowcasting setup (personalized stream per mountpoint). The streams itself are created in a piece of proprietory (spelling?, i'm dutch) software, icecast merely relays them. However, the intended endpoint is an embedded device. This device has trouble with tcp/ip packets not matching the max. packet size (MSS or MSS minus header). After eleborate testing,