similar to: Stream drops during handoff. Suggestions?

Well, I see ezstream 0.2.0 is downloadable, so I downloaded it and tried to compile. Unfortunately it won't compile for me. The configure script runs fine. Here's the output of make. Joel make all-recursive make[1]: Entering directory `/home/jbebel/ezstream-0.2.0' Making all in src make[2]: Entering directory `/home/jbebel/ezstream-0.2.0/src' source='ezstream.c'

Sorry if this has been asked before, but I've searched high and low for the last couple days for an answer. An Internet radio station I DJ for is using Shoutcast and MP3, but we are considering moving to an Icecast/Ogg Vorbis combination instead. We work in 3-hour shifts. When we hand off, the DJ on-stream stops teh encoder, shouts "go" on IRC, and the DJ in line starts his

Thanks for the status on the trunk version. I'll give the trunk version a whirl and start using it heavily :-) and report back if there are any problems. Cheers, KJ > > Van: Karl Heyes <karl@xiph.org> > Aan: Klaas Jan Wierenga <k.j.wierenga@home.nl> > CC: icecast <icecast@xiph.org> > Datum: di 7 sep 04, 19:55 > Onderwerp: Re: [Icecast] fallback to static

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 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:

Michael Smith wrote: > On Thu, 13 Jan 2005 13:19:08 -0500, Joel Ebel <jbebel@ncsu.edu> wrote: > >>I asked this questions before, but I think it got lost/ignored in all >>the traffic. So I'm asking it again. >> >>Why would my clients number always be 113 larger than my number of >>listeners? It was right earlier today, but when I restarted the

Hi Karl, I've not been able to duplicate it (yet). Assuming that brendan's snapshot is a daily build from icecast/trunk I've compared icecast_2_3_1 and trunk code for src/source.c. The most likely change that fixes the problem is the introduction of avl_tree_rlock (and matching unlock) just below "Applying mount information for". Another lock that might be related is

Again, forwarding to the list. Please try to reply to the list. Cheers, KJ -----Oorspronkelijk bericht----- Van: Iceuse - Kris [mailto:iceuse@wwlang.net] Verzonden: woensdag 15 september 2004 7:17 Aan: k.j.wierenga@home.nl Onderwerp: Re: [Icecast] SOURCE access logging in 2.1-trunk breaks webalizer (streaming version) Thanks, I'm very confused by this kind of lists where the answer goes to

On Thu, 13 Jan 2005 13:19:08 -0500, Joel Ebel <jbebel@ncsu.edu> wrote: > I asked this questions before, but I think it got lost/ignored in all > the traffic. So I'm asking it again. > > Why would my clients number always be 113 larger than my number of > listeners? It was right earlier today, but when I restarted the sources > it increased by 113, and it has stayed

On Tue, 2004-09-07 at 17:54, Klaas Jan Wierenga 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

Posting it on the mailing list for you Chris :-) KJ -----Oorspronkelijk bericht----- Van: Iceuse - Kris [mailto:iceuse@wwlang.net] Verzonden: dinsdag 14 september 2004 16:49 Aan: Klaas Jan Wierenga Onderwerp: Re: [Icecast] SOURCE access logging in 2.1-trunk breaks webalizer (streaming version) Hello, Yes, that's something which is making trouble with webalizer stats... when I made this

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

Yes that is the plan. I'll have to find some time to graft the patch onto 2.1 mainline and post it here. KJ -----Oorspronkelijk bericht----- Van: Myke Place [mailto:mp@trans.xmission.com]Namens Myke Place Verzonden: donderdag 18 november 2004 22:14 Aan: Klaas Jan Wierenga Onderwerp: Re: [Icecast] Dumping streams to a file? Is the plan to eventually move this from -trunk to the mainline

I discovered an interesting problem with ezstream. I'm using version 1.2. I see 2 is listed on the website but appears to be a broken link. Otherwise I'd try it to see if it exhibits the same problem. I'm using ezstream as a fallback mount for a radio station. It plays a 30 second ogg file over and over. The ogg file is just a 5 second message with 25 seconds of silence

On Thu, 13 Jan 2005 19:11:08 -0500, Joel Ebel <jbebel@ncsu.edu> wrote: > > - icecast version (and what platform you're running it on) > Icecast 2.2.0 running on Slackware Linux 10.0 > > > - icecast config file (with passwords blanked out, of course) > Config file is attached > > > - description of _precisely_ what figure you're looking at

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 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

Please post to the mailing list the next time Ralf. 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: -----%< cut here > ls -R .: admin etc lib opt usr var web ./admin: listclients.xsl listmounts.xsl

On 6/1/05, Joel Ebel <jbebel@ncsu.edu> wrote: > My icecast server has been running happily for months now, but just > yesterday it locked up, chewing up all the cpu time it could find, and > not allowing connections. The last snippet of the error log shows this: snip... > The error had repeated itself for almost 24 hours before I noticed it. > Obviously it had too many files

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