similar to: CPU Utilization Weirdness

Well, thought I would try one stream only to see if that makes a difference. Apparently not. Here is a listing of the logs and I have attached the conf file and the startup scripts that I use. icecast.log [06/Feb/2002:14:45:25] [1:Calendar Thread] directory_touch_xa([yp.icecast.org:80]) completed...server id = 69 [06/Feb/2002:14:46:19] [96:Connection Handler] Kicking source 92 [192.168.1.5]

On Tuesday, 10 July 2001 at 03:21, Nick Ludlam wrote: > From: "Brendan Cully" <brendan@icecast.org> > > That handles the segfault, I don't know why the stream wouldn't be > > sent fast enough though... > > Tried with winamp, sonique and freeamp. All exhibit the same problem of > stuttering play, and eventually this drops out of the icecast log: >

On Tuesday, 10 July 2001 at 14:10, Nick Ludlam wrote: > From: "Brendan Cully" <brendan@icecast.org> > > On Tuesday, 10 July 2001 at 03:21, Nick Ludlam wrote: > > > From: "Brendan Cully" <brendan@icecast.org> > > > > That handles the segfault, I don't know why the stream wouldn't be > > > > sent fast enough though...

From: "Brendan Cully" <brendan@icecast.org> > On Tuesday, 10 July 2001 at 14:10, Nick Ludlam wrote: > > From: "Brendan Cully" <brendan@icecast.org> > > > On Tuesday, 10 July 2001 at 03:21, Nick Ludlam wrote: > > > > From: "Brendan Cully" <brendan@icecast.org> > > > > > That handles the segfault, I

From: "Brendan Cully" <brendan@icecast.org> > Sorry Nick, I lost your last mail. One last thing, did you make clean > && make? The dependencies are not generated properly for ices, so even > if libshout got rebuilt it might not have been relinked. There's no other libshout on the system. Have rebuilt from scratch and it still exhibits the timing problems.

From: "Brendan Cully" <brendan@icecast.org> > On Tuesday, 10 July 2001 at 03:21, Nick Ludlam wrote: > > From: "Brendan Cully" <brendan@icecast.org> > > > That handles the segfault, I don't know why the stream wouldn't be > > > sent fast enough though... > > > > Tried with winamp, sonique and freeamp. All exhibit the

On Tuesday, 10 July 2001 at 01:26, Nick Ludlam wrote: > Not got to the bottom of it yet, but commenting out both LOG_INFO > lines in thread/thread.c stops it segfaulting. Now I'm back to the old problem > of a 128k stream not being sent fast enough to the clients. you should just be able to increase STACKSIZE in thread/thread.c from 8192 to 65536. The default stack size is too small,

# HG changeset patch # User Brendan Cully <brendan@cs.ubc.ca> # Date 1166470577 28800 # Node ID 18d9894cb78627cf743a2df98f29e22d3ffd7819 # Parent 469478194aef6e987f9281efbc0756749be6eb80 Disable GCC stack protection in kernel builds. Without this flag, the kernel won''t build on Ubuntu 6.10. Signed-off-by: Brendan Cully <brendan@cs.ubc.ca> diff -r 469478194aef -r

Did some more experimenting last night. When I changed icecast and ices back to 'daemon mode' they lasted for about 5 songs, before tanking. I then tried combinations of icecast as a daemon and ices not, and vice versa - same results. Even recompiled without any mods to icecast. The only thing that seems to work is starting the processes and piping them to null. The only disadvantage to

Made the change and so far so good, CPU is back where it should be. Running 2 streams at 56K 22Hz is using about 5% CPU total - most respectable I think. I have only been running this config for about 10 minutes, but so far so good. Will post follow up tomorrow. Thanks Jack - question tho: isn't using console mode 3 the same as using -b (from the description in the conf file anyway) or it is

Using Icecast 1.3.11 and Ices 0.2.2. Have compiled Ices with the optimize flags defined. Using PII 266 - 160MB, RH 7.1 with default kernel (2.4.7 i think) Situation that I have is interesting: 1) Bring icecast up in the foreground and everything is well. Works as expected. Bring ices up in the foreground in another session and it too works as expected. System will run well until I take it down.

Okay. It died again after about 4 hours. I will turn off the yp servers and see if that helps. Any other ideas? Same thing, BTW, ices reported a libshout error. Hunter > From: Brendan Cully <brendan@icecast.org> > Reply-To: icecast@xiph.org > Date: Mon, 27 Aug 2001 12:56:58 -0400 > To: icecast@xiph.org > Subject: Re: [icecast] Icecast Problems Get Worse > > I

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

At 05:19 PM 2/4/2002 -0500, Gary Major wrote: >Using Icecast 1.3.11 and Ices 0.2.2. Have compiled Ices with the optimize >flags defined. Using PII 266 - 160MB, RH 7.1 with default kernel (2.4.7 i >think) > >Situation that I have is interesting: Odd, I have them both running as background processes together with no problem (then though I'm running FreeBSD 4.5-STABLE). And I

From: "Brendan Cully" <brendan@icecast.org> > > Going through the icecast source, wouldn't it make sense to select() on the > > source data socket instead of just sleeping for an arbitrary amount of time? > > Since ices is controling when it sends data, you can just read as necessary > > at the icecast end. I'm not really happy running icecast with

From: "Brendan Cully" <brendan@icecast.org> > On Tuesday, 10 July 2001 at 16:50, Nick Ludlam wrote: > > From: "Brendan Cully" <brendan@icecast.org> > > > Sorry Nick, I lost your last mail. One last thing, did you make clean > > > && make? The dependencies are not generated properly for ices, so even > > > if libshout got

From: "Brendan Cully" <brendan@icecast.org> > On Tuesday, 10 July 2001 at 16:50, Nick Ludlam wrote: > > From: "Brendan Cully" <brendan@icecast.org> > > > Sorry Nick, I lost your last mail. One last thing, did you make clean > > > && make? The dependencies are not generated properly for ices, so even > > > if libshout got

On Tue, 24 Jul 2001, Brendan Cully wrote: | you can get the not-open-source version free from shoutcast.com. Your | symptoms imply that you may be trying to stream high-bitrate MP3s? | (that would be 160kbit+). For starters, try setting sleep_ratio to 0 | in icecast.conf. Although it burns more CPU it may save you some | grief. Alternatively you could try checking out icecast from CVS, | although

On Thursday, 19 June 2003 at 02:17, Arc wrote: > On Wed, Jun 18, 2003 at 09:20:23PM -0400, Brendan Cully wrote: > > Libshout 2.0, the icecast 2 compatible streaming library, is now in > > did you resolve the return value issue that was addressed before? what return value issue? > also, and I dont know if this should be release-dependent, but I'd > really like to see

From: "Brendan Cully" <brendan@icecast.org> > On Tuesday, 10 July 2001 at 01:26, Nick Ludlam wrote: > > Not got to the bottom of it yet, but commenting out both LOG_INFO > > lines in thread/thread.c stops it segfaulting. Now I'm back to the old problem > > of a 128k stream not being sent fast enough to the clients. > > you should just be able to