similar to: more ices errors

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

On Wednesday, 27 June 2001 at 14:08, Kirk Reiser wrote: > 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

Hi all: Well, after making the change to make use of the CVS trees and switching to ices2 (as opposed to the libshout example streamer), the icecast server at bumpy.braille.uwo.ca:9000 is back up. I've put my old 22khz mono files (encoded with beta4) back up on test.ogg. In addition, we've implemented a vorbis subset of Kirk Reiser's egoplay MP3 stream. You can now hear all the

Hi all: Well, after making the change to make use of the CVS trees and switching to ices2 (as opposed to the libshout example streamer), the icecast server at bumpy.braille.uwo.ca:9000 is back up. I've put my old 22khz mono files (encoded with beta4) back up on test.ogg. In addition, we've implemented a vorbis subset of Kirk Reiser's egoplay MP3 stream. You can now hear all the

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

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

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

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.

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

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

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

Well, actually you have from Geoff Shang. You stated at the time you would look into it after exams or the like. Geoff said he would post an official bug report but hasn't managed it yet. For the record: Using cvs ices2, libshout and icecast2 and can't remember what else but all cvs. Ices runs almost 24 hours before it leaks all the memory it can get and all the processes get killed

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

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

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.

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