similar to: ices users, please test the ices in CVS

Brendan Cully <brendan@kublai.com> writes: > Well, it didn't work until yesterday, when I checked in a new > version. As a matter of fact it only works with extremely current lame > CVS, some things in lame were just fixed which would cause the current > code to crash in versions older than June 7. Talk about coincidences! I didn't have time until yesterday afternoon

Hi, Since I got no negative feedback (or any feedback) about the autoconf changes I did a couple days ago, I've released ices 0.1.0 at http://www.icecast.org/releases/ices-0.1.0.tar.gz This is mostly a collection of minor bugfixes, plus an update to the reencoder to use the current LAME API. Note you'll need at least LAME 3.88beta to use reencoding. From the changelog: - 0.1.0

Hi Brendan: The diff patched, configured and compiled just greate. A bit of a false start because I chose a bitrate lame didn't like. Once I figured that out however things went fine. You might want to log the point lame dies on something which would help others know where to look for lame errors. On another note, I see ices still only accepts /tmp for the ices:Basedirectory tag. I hope

Hi all: I was just wondering when the multiple streams stuff might be checked in to cvs. I remember the gentleman working on it saying he basically had it running? The reason I'm asking is that I have received a number of requests to stream my mp3 stream at various bitrates. I kind of think running three ices streamers is silly if multiple streams will be available in the near future.

Well, hi folks: I am still having this problem with ices crashing regularly. I have upgraded to todays cvs for ices and icecast hoping that would take care of it but no such luck. I am not sure just what is going on. It seems to happen fairly often which is not exactly making my listeners happy. I will include the relevant portion of the ices.log below. I would appreciate any suggestions

Hi Folks: I am either using the multiport of the -m or --match option of iptables in correctly or there is a bug with it. Is anyone else using it with no problem? This is the way I am trying to use it: my_ports=21,25,80 iptables -t nat -A PREROUTING -i $wan_addr -p tcp -m multiport --dports $my_ports -j DNAT --to $my_internal_address I have used this in the past successfully but that was a

At 06:32 AM 31/10/2002 -0500, you wrote: >I've noticed with the cvs ices that the more memory which is leaked >the higher the load average gets until just before all the ices >processes get killed off by the kernel. During normal operations with >three reencoding streams the average pretty much stays around .050 to >1.2. > I've had no reports of memory leaks or

Hi Brendan and all: Well the upgrade libshout didn't fix the problem. Here are more logs from ices and icecast. They certainly don't tell me much. DEBUG: Builtin playlist handler serving: /var/music/Mercyful_Fate/Time/Mercyful Fate - 09 - Mirror.mp3 DEBUG: ID3v1 song: Mirror DEBUG: ID3v1 artist: Mercyful Fate DEBUG: Layer: III Version: MPEG-1 Frequency: 44100 DEBUG: Bitrate: 128

I am having one slight weirdness which I haven't been able to put my finger on yet. About once every other day or so ices dies with an error about libshout not being able to reconnect to the server. I am not sure who is guilty here ices or icecast. Unfortunately it only happens rarely, twice so far, I'll let you folks know more if I can get a better handle on it. Kirk -- Kirk

At 06:36 PM 11/7/01 -0500, you wrote: >Okay, I am re-encoding the 64bps stream from the 128 encoded files in >the 1000 play list. I'll try shutting that down and see if that helps >before I update cvs. Some days the play list gets reloaded a number >of times because I'm adding new material. Other days it does not. I >haven't added anything for the past 4 or 5 days

At 02:53 PM 30/10/2002 -0700, you wrote: >Bastard is used in a negative context here :) A snippit of a top >command reveals: > >PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND >3246 root 15 0 2436 2436 1280 S 10.5 3.9 0:14 ices > > >I am re encoding using: > > <encode> >

> Um, why wouldn't you just use apache for this? Exactaly, I would recommend the mod_mp3 project for something like that. http://media.tangent.org/ They are doing almost exactaly what sound like you are looking for. There is also the project 'ampache' that takes this one step further and adds a MySQL database backend to a PHP front. JStanley --- >8 ---- List archives:

At 06:36 PM 11/7/01 -0500, you wrote: >Okay, I am re-encoding the 64bps stream from the 128 encoded files in >the 1000 play list. I'll try shutting that down and see if that helps >before I update cvs. Some days the play list gets reloaded a number >of times because I'm adding new material. Other days it does not. I >haven't added anything for the past 4 or 5 days

Hi Brendan and all: Well, the last set of changes you made didn't get rid of the problem but the error messages certainly coincide with the icecast.log messages now. So is the problem icecast or ices? Here is just the last set of messages which caused it to die. There were many more through out the file but they didn't hit the magic ten consecutive. DEBUG: Builtin playlist handler

At 08:09 AM 11/7/01 -0500, you wrote: >Hi everyone: I am running a couple of ices2 streams one with a fairly >small playlist and one with a play list which is currently about 1000 >pieces. The 1000 piece stream appears to have a bad memory leak. The >streamer dies about every 16 to 20 hours with a process out of memory >error. Has anyone else seen this problem or have any

Hello Folks: Every now and then my ogg123 quits while loistening to the stream. It isn't a bandwidth problem because my ogg123 is on a machine which is just a few feet from the server and is in fact on the same machine with ices2 doing the streaming. It happened this morning and I decided to take a look at the log and found some curious messages and thought maybe I'd post them here and

> > It is my understanding that you have the highest bitrate stored and you > > just want to re-encode the files on the fly over a stream. You do this > > rather than just store all the different enc rates. > > Basically yes. The material I have available is currently over 30gb > and growing. If I stored all the various combinations of bit rates > the storage

A question.... How much the streaming will be better using Squid as HTTP accelerator for the streaming? The users will connect against Squid instead directly to Icecast. Squid will connect to Icecast. This must permit more users at the same time by using the cache of Squid. Anyone has installed this? I´m studing this but if someone has another idea or a reason to not do this, please say to me....

Hey all, I've been having the same "Client not receiving data fast enough" errors. I've got icecast configured so as not to send info to ANY yp directories. Even on a quiet 100MB connection between client and server, I can stay connected for only about 5 minutes at a shot if I'm lucky. I'm using Icecast 1.3.11, and Shout 0.8.0. The files I'm streaming are all

I am having a problem with darkice and i was hoping that you could help me. i'm running freebsd 4.2. i had icecast-1.3.7 and darkice-0.7. icecast was +building to 100% cpu so i up'd it to 1.3.11. icecast now runs at a reasonable +cpu but i'm getting the following error when i try to start darkice: