similar to: FW: Tip: using icecast in chroot mode may break timestamp inaccess.log

Do you mean you can relay within a single icecast server instance? So the relay is running on the same icecast process from which it is relaying a stream? KJ -----Oorspronkelijk bericht----- Van: Karl Heyes [mailto:karl@xiph.org] Verzonden: maandag 15 november 2004 22:18 Aan: Klaas Jan Wierenga CC: icecast Onderwerp: Re: FW: [Icecast] Multi-Level Fallbacks On Mon, 2004-11-15 at 20:36, Klaas

In my case that's not needed, but yes it would be really nice if all mount options could be retrieved from the database using an authenticated URL. KJ Stefan de Konink wrote: > On Fri, 8 Sep 2006, Klaas Jan Wierenga wrote: > > >> I guess if the <authentication type="url> section could be used as a >> top-level tag (instead of as a sub-tag of

Hi Karl, Thanks for your info. I have a standard Icecast-2.2 release with a few local patches. I'm a little apprehesive to apply my patches to the kh14 branch, so I'd rather patch my branch with the changes related to batched reads from the kh branch. I've looked at your code to see if I could spot the changes related to batching reads. So far I have not been able to find where

Hi, I have used the SVN icecast-2.1-trunk version in my production system at http://audioserver.nl for 2 months now without problems. The fallbacks work fine as long as you make sure that the format (sampling frequency and bitrate) of the mount and it's fallback match. I have also patched the icecast-2.1-trunk version (patch not published yet, needs work to extract) to enable fallback of

Hi all, I have an icecast setup with 20+ sources. During peak times some 20 sources will be connected with a total of some 250 listeners more-or-less equally divided over the 20 sources. All streams are running at a measly 16 kbps. There is enough bandwidth to/from the server. During these peak times I see very high CPU usage for icecast 98-99%. The system I'm running is an Intel Celeron

Karl, I've managed to patch up my branch of Icecast to do the batching. Checked everything with valgrind and tested it extensively. It looks good. Tcpdump now shows nice size frames (mostly 1400 bytes). Any reason why you're not settings the MTU to something closer to 1500? Many thanks for your help, KJ -----Oorspronkelijk bericht----- Van: Karl Heyes [mailto:karl@xiph.org] Verzonden:

Hi all, The URL authentication is great for reducing the administration overhead in running one or more icecast instances for lost of mountpoints and lots of listeners. However because the URL authentication is <mount> specific you still need to create a mountpoint for each (in our case) customer. Would it be possible to have a global URL authentication section which would apply to

Hi all, I have a question about the relationship between the "queue-size" and the "burst-size" <limits> parameters. Q: When a client connects is the burst-size immediately added to the queue-size? If this is the case then the slack for a 16kpbs client goes down from 50 sec (102400[queue-size] / 16kbps = 50 sec) to 18 seconds ( (102400 - 65536[burst-size]) / 16kpbs =

Hi, You can if your machine is assigned two IP addresses. Then you can bind the webserver to port 80 on the first IP-adres and bind icecast to port 80 on the second IP-address. Hope this is helpful. Regards, KJ -----Oorspronkelijk bericht----- Van: icecast-bounces@xiph.org [mailto:icecast-bounces@xiph.org]Namens Laust Brock-Nannestad Verzonden: woensdag 22 juni 2005 2:27 Aan: icecast@xiph.org

(I'm aware that this patch is not likely to be accepted in the upstream source because Icecast doesn't really support MP3, but I thought it worthwhile to send it here in case anyone wishes to modify their local source with it.) Background: Icecast does not make any attempt to demarcate the boundaries between MP3 frames, and when a listening client connects to the server it generally

Hi Geoff, Thanks, that sounds like a good idea. I've just tried it and of course it works. Then I discovered that when the original source is not connected icecast doesn't fall through to the fallback mount. Is this a known problem? KJ > > Van: Geoff Shang <gshang@pacific.net.au> > Aan: Klaas Jan Wierenga <k.j.wierenga@home.nl> > CC: icecast@xiph.org > Datum:

On 22 Mar 2003, Karl Heyes wrote: > ethereal is a good tool for that, start a capture (maybe with a capture > filter of "port <port>" or "host <ip>" to limit it if the box has plenty > of traffic), connect the source, wait a second then stop the capture. > Pick one of the packets that relates to the source stream and do > tools->follow tcp stream.

I'm curious about why you would want to run Icecast on port 80. Geoff Justin Bot wrote: >Care to shed some light on this? I have about 10 IPs that are at my >disposal and 3 I've been keeping for spares and whatnot. Though >binding them is a little beyond me. > >TIA > >Justin > >On 6/22/05, Klaas Jan Wierenga <k.j.wierenga@home.nl> wrote: > >

Karl, It would certainly be a useful feature for me and I guess others. The current solution with ezstream works but listeners all end up at the same (current) point in the mp3 file. With the mp3 file as a fallback each individual listener would want to start hearing it from the start. This might be more difficult to implement with the single-q that is in the current trunk code, I don't know.

Hi, I've been using icecast-2.3.1 for some time now and it is really working well for me, 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 have a patch on icecast-2.2.0 svn version which was written specifically to support SimpleCast users to retrieve the stats for their mountpoint and only that mountpoint. This is based on per mount-point username password. Using HTTP authentication the client can retrieve only http://hostname/admin/stats.xml given the correct username/password. This will only return the stats for that

Hi all, I'm running an Icecast-2.2 server with at peak times some 50 sources and 500 concurrent listeners all using low-bitrate 16kpbs streams. I'm experiencing some connection losses at these peak times ("Client connection died" message in error.log). The machine running Icecast has a 100Mbit connection to the internet. It is a Celeron 2.4Ghz machine with 1Gbyte of main

> Klaas Jan Wierenga wrote: > > > I'm not using yp directory listings, but I can guess why it is not > > working. > > You're probably missing the libcurl.so library in your chroot jail > > directories. Here's the listing of files I have in the chroot jail: > > Definitely not, I rebuilt the whole lib structure i got from > ldd in my chroot But

Klaas Jan Wierenga wrote: > Hi Henri and others, > > Very interesting post about TCP_CORK. I would be very interested in having > it applied in the next version of Icecast. I'd be more interested in some figures to show there being a benefit, most examples talk about HTTP servers with short lived connections where sendfile(2) is used. > For low-bitrate streams the problem

On Sat, 2003-03-22 at 15:20, Geoff Shang wrote: > And here's the problem, right in the icecast error log: > > [2003-03-21 23:59:18] EROR yp/yp_submit_url Got a NAK from yp_add(Bitrate > blank) (http://www.oddsock.org/cgi-bin/yp-cgi) > [2003-03-21 23:59:18] EROR yp/yp_submit_url Got a NAK from yp_touch(SID > blank) > (http://www.oddsock.org/cgi-bin/yp-cgi) > >