similar to: Possible bug with multiport?

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

Hi, I've been doing some work on ices, and I'd like to put out a release shortly so I can get to work on MultiStreaming (tm). Some bugs are fixed (eg now ices:BaseDirectory works (but note it is no longer called ices:Base_Directory - I figured since it was broken odds were good no one was using it), and song length is correct in the cue file), but mostly I've done a ton of work on the

Hi, I've been doing some work on ices, and I'd like to put out a release shortly so I can get to work on MultiStreaming (tm). Some bugs are fixed (eg now ices:BaseDirectory works (but note it is no longer called ices:Base_Directory - I figured since it was broken odds were good no one was using it), and song length is correct in the cue file), but mostly I've done a ton of work on the

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

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

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

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.

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

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

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

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

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

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

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

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

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:

> happily use it. My system works pretty well except for a number of > small issues I am still working on. 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. Correct my assumption, but can't ices create playlists from perl scripts?