similar to: No subject

Brendan Cully wrote: > > The format of ices.conf changed somewhat in 0.2, to support multiple streams > from the same playlist with different reencoding options. In short, these > settings have been moved into the Stream node. For more info have a look > at the sample ices.conf included with the distribution. I did modify my ices.conf when I made the upgrade. Here's my

I did some further investigating into this issue and here's what I found: It appears somewhere between ices0.1.0 and ices 0.2.0 is where the "bug" (for lack of a better term) was introduced that i'm noticing. When I compile ices0.2.0 w/lame 3.89beta, the VBR is *NOT* reencoded, but instead streamed out at full VBR bitrate(s). However, when using ices0.1.0 w/lame 3.89beta, it

Any help would be appreciated, not sure why this isn't compiling: Redhat 7.2 [root@jasmine ices-0.2.2]# ./configure --with-lame loading cache ./config.cache Building ices 0.2.2... checking for a BSD compatible install... (cached) /usr/bin/install -c checking whether build environment is sane... yes checking whether make sets ${MAKE}... (cached) yes checking for working aclocal... found

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

Thanks for the suggestion. It turns out that debug for ices told me nothing but debug for icecast 2.2.0 showed that it was terminating the source at the same place in the playlist, apparently due to a lack of trailing metadata in one particular file -- icecast saw it as end of stream. After checking code updates on the TRAC system, I installed the kh branch of icecast (kh13) and this seems

On Wednesday, 28 November 2001 at 12:43, Bolt Thrower wrote: > > The format of ices.conf changed somewhat in 0.2, to support multiple streams > > from the same playlist with different reencoding options. In short, these > > settings have been moved into the Stream node. For more info have a look > > at the sample ices.conf included with the distribution. > > I did

Brendan Cully wrote: >>kill -SIGHUP <icespid> >>But this don't work! :( > > That should work. Hmm ... How can I recognize, that the changes are detected? I Changed the playlist, sent the kill -SIGHUP command, and watched the cue File. But nothing changed. Or ... did ices finished playing the current song and starts after that the new song from the new playlist?

Great. If you have some pointers with further explanations, that'd be great, because lately I've been wondering why 256 MB fills up all the way to the point my desktop system slows to a crawl. Someone seriously messed with the 2.4.x memory handling. It's probably caching and mmap'ing lots of stuff but I want it to pipe DOWN ! o any pointers are appreciated. Especially on the

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

i'd also point out that memory "use" under linux can be deceptive. -----Original Message----- From: owner-icecast@xiph.org [mailto:owner-icecast@xiph.org]On Behalf Of Brendan Cully Sent: Monday, September 10, 2001 4:00 PM To: icecast@xiph.org Subject: Re: [icecast] Ices memory leak? On Monday, 10 September 2001 at 12:45, Jason Mansfield wrote: > Is anyone else experiencing what

Anyone have any idea what might be causing this error during compiling? .... gcc -g -O2 -Wall -o ices ices.o log.o setup.o stream.o util.o mp3.o cue.o metadata.o id3.o signals.o reencode.o ices_config.o playlist/libplaylist.a ../resolver/libresolver.a ../thread/libicethread.a ../avl/libiceavl.a ../log/libicelog.a -lpthread -lshout -lmp3lame -rdynamic -L/usr/local/lib

Hello, I've noticed that when I try to reencode VBR mp3s to broadcast @128k , they are not being reencoded at all. They stream as normal VBRs I am unable to reproduce this at lower bitrates (56-112k i've specifically tested and all work fine). It does reencode all non-VBR mp3s appropriately to 128k... Any ideas why VBR reencoding would suddenly stop working at 128k? I've attempted

On Saturday, 23 February 2002 at 00:51, lists@returntonature.com wrote: > Any help would be appreciated, not sure why this isn't compiling: You have an old version of libshout installed. The configure script should probably be updated to check for shout_strerror instead of shout_init_connection, but in the meantime either remove your old libshout (probably in /usr/local) or try compiling

Hi I am writing a python test suite that uses oz (https://github.com/clalancette/oz) which uses libquestfs. I am simulating a small cloud and have some apps that need to talk to the guests. All works really well until I needed to start another process. So I start a process then "oz" starts up a VM (it uses libquestfs) then when "oz" cleans up it calls

>> stable Ices 0.2.2 is? Are there enough fixes in it that it's worth using it? > > I wouldn't run anything but the current code. Brendan is pretty > good about fixing bugs if you run into any. A few people have been > using 0.2.2 for a while. Does ices 0.2.2 show the album name in the meta information, or just the artist & songname? Thanks, Mark --- >8 ----

On Sat, Mar 23, 2002 at 07:13:44PM -0700, Jack Moffitt wrote: > > I posted a while back about having trouble with ices 0.2.2 being > > able to re-encode VBR mp3s, and the response was that ices 0.2.2 did > > not reencode VBR mp3s. Are there any plans to include such support > > in future ices versions? If so, any ideas as to when such versions > > would become

looks like you need to set CPPFLAGS="-I/usr/local/include" and LDFLAGS="-L/usr/local/lib" in your configure environment. <p>Quoting Luiz Claudio Duarte <lclaudius@luiz.claudio.nom.br>: > Also sprach Michael Smith: > > > > >Ok. I'm using shout and not ices (I couldn't get it to compile; > I'm > > >using FreeBSD and

Also sprach Michael Smith: > > >Ok. I'm using shout and not ices (I couldn't get it to compile; I'm > >using FreeBSD and can't code C worth a damn), so the second approach > >will not work. But I can write a parsing script (I had'n thought of > >the cue file), so I'll be trying that. > > Please don't use shout. It's buggy,

Also sprach Bolt Thrower: > On Fri, Mar 29, 2002 at 03:00:35PM -0300, Luiz Claudio Duarte wrote: > > Hi, folks. I've installed icecast 1.3.11 and I'm very happy with > > it. But I'd like to add a "now playing" gizmo to my home page; > > can anyone point me to a php script or something else that does > > the trick? Thanks in advance. > > Two