similar to: Newbe: OK so far?

On Thursday, 23 August 2001 at 21:16, Scott Vetter wrote: > The source is for ices-0.1.0. The errors occurs at the compile within the make for > parse.c. > > The errors are: > parse.c:41 parse error before 'doc' (same for 42 and 43) > parse.c:44: parse error before 'ices_xml_get_root_element' > parse.c:45: parse error before

On Thursday, 23 August 2001 at 20:48, Scott Vetter wrote: > I tried the 3.70 rpm and received an error that rpm couldn't handle the > version of whatever packaged it. So I had to do things by getting the source > and compiling. The same was true with lame. > > Also I copied all the lame headers to the /usr/local/include directory, did > the ./configure which seemed

Mr. Cully: Thanks for replying. Any idea where I can find such for a SuSE 6.3 system? I've looked at Yast's installable features and there is no such thing... Thanks, Scott ----- Brendan Cully wrote: > On Wednesday, 22 August 2001 at 17:53, Scott Vetter wrote: > > Now for ices, I've gotten through the "./configure" and get several > > error

The source is for ices-0.1.0. The errors occurs at the compile within the make for parse.c. The errors are: parse.c:41 parse error before 'doc' (same for 42 and 43) parse.c:44: parse error before 'ices_xml_get_root_element' parse.c:45: parse error before 'ices_xml_get_children_node' parse.c:45: parse error before 'cur' and the rest are warnings. Scott -------

On Wednesday, 22 August 2001 at 17:53, Scott Vetter wrote: > Now for ices, I've gotten through the "./configure" and get several > error messages: > parse.c:45 parse error before 'ices_xml_get_children_node' > parse.c:45 parse error before 'cur' > > Unfortunately I cannot scroll back to see what the first error might > be. And just getting to

> OK, I found LAME's web site and installed it using the source for it. That > appears to work. I also found a couple of libxml... packages and either > replaced the existing ones and added a few others. That went without problem. > However the same problem exists. I found that the lame.h file is in a > directory of /root/lame3.70 Perhaps the make can't find it at

I tried the 3.70 rpm and received an error that rpm couldn't handle the version of whatever packaged it. So I had to do things by getting the source and compiling. The same was true with lame. Also I copied all the lame headers to the /usr/local/include directory, did the ./configure which seemed to work and then did the make, which didn't. Any other ideas? Thanks, Scott ANGEL

Where can I find the 3.87 version of LAME? I've seen nothing later than 3.80 and this was just for documentation. The place I'm looking is lame.sourceforge.net. Perhaps you know a site that has the latest and greatest... Scott -------- Thomas Vander Stichele wrote: > > OK, I found LAME's web site and installed it using the source for it. That > > appears to work.

Never mind I found the latest version of LAME and got the 3.87 version as you mentioned. When I did the gmake (interesting that it is no longer make) it still got the same errors. I copied the lame.h file to the directories /usr/local/include, /usr/local/include/lame, and even to the same directory as ices and still got the same error! Any ideas what to try next? Thanks, Scott -----

----- Original Message ----- From: Thomas Vander Stichele <thomas@urgent.rug.ac.be> To: <icecast@xiph.org> Sent: Thursday, August 23, 2001 8:58 AM Subject: Re: [icecast] Newbe: OK so far? > > OK, I found LAME's web site and installed it using the source for it. That > > appears to work. I also found a couple of libxml... packages and either > > replaced the

OK, I found LAME's web site and installed it using the source for it. That appears to work. I also found a couple of libxml... packages and either replaced the existing ones and added a few others. That went without problem. However the same problem exists. I found that the lame.h file is in a directory of /root/lame3.70 Perhaps the make can't find it at this directory? IS there

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

I've just released ices 0.3: http://icecast.org/files/ices/ices-0.3.tar.gz ices 0.3 is an encoder for icecast-compatible servers (including icecast 2, icecast 1 and shoutcast). It requires libshout 2.0. ices 0.3 outputs MP3, not Vorbis. For Vorbis you will need ices 2. We know this is confusing, so ices 0.x will probably have a new name for the next release. Ideas? Changes since ices

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

FYI, I've added a crossfader to the ices0 trunk in subversion: http://svn.xiph.org/icecast/trunk/ices0 It requires LAME support (of course). To use it, either pass -C <secs> on the command line, or add a <Crossfade>secs</Crossfade> node to the Playlist section of the config file. Reencoding must also be enabled on your stream. NOTE: the crossfader can't resample, so all

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

Due to a minor reorganization of the CVS tree, cvs update of libshout will fail on the m4 directory. Either do a fresh checkout or remove your m4 directory and check out cvs.xiph.org:/usr/local/cvsroot m4 in its place. ices (0 and 2) and icecast may be going through the same process soon. I'll let you know when it happens. -b --- >8 ---- List archives: http://www.xiph.org/archives/

At 1:48 PM -0400 7/6/01, Brendan Cully wrote: >On Friday, 06 July 2001 at 10:32, tom erbe wrote: >> icecast 1.3.10 is the server i'm running, but its ices 0.1 that gives >> me a segfault under solaris. it works just fine on my linux box. ices > >The segfaults are a stack size problem. Try changing STACKSIZE near >the top of thread/thread.c from 8192 to 65536 or so...