similar to: problem with config file for jack with ices2-kh-2.0.0-kh60a

Hiya Karl (and everybody else), I noticed today that ices 2.0-kh60a came out last January, and opted to give it a try. Unfortunately, it just wouldn't work at all, so I had to back down to 2.0-kh60. What I get in my log is this: [2006-04-21 21:16:18] DBUG om_shout/check_shout_connected Time we started stream on ice.imars.net:8000/cigr.ogg [2006-04-21 21:16:19] EROR

tobias wrote: > hi, > > i am desperately trying to get this version of ices up and running on debian > etch. i used the apt repository at http://www.fbriere.net/debian/ices2/ but i > found this also affects the "official" source package at > http://mediacast1.com/~karl/ > when i try to run an edited version of either the example file provided with > the

On Sat, Apr 22, 2006 at 01:45:27PM +0100, Karl Heyes wrote: > >I should point out that the server is 2.0.0. (Yeah, I know how old that > >is. Unfortunately, I only manage the client; the server is out of my > >hands.) Has anything changed in 2.0-kh60a that would require a more > >recent version of icecast? > > wow, v2.0.0 is old, won't make a difference for

On Sun, 2005-02-20 at 12:15, Fr?d?ric Bri?re wrote: > I've been running ices2 like this 24/7 for months now, only restarting > it once a week for log rotation. Never had a problem since. setting <logsize> will cause an automatic log rotation when a certain file size has been reached. It renames <logfile> to <logfile>.1 then opens a new file <logfile> karl.

Hi everybody, I'm in charge of an ices2 setup that's broadcasting a local radio station on the Net, and I'm currently under fire because one of our streams has been down twice in two days, forcing me to restart ices2 on each occasion. Our client is understandably unhappy about this. OUR SETUP: I've got ices2 installed on a local machine, broadcasting to an icecast server across

hi everyone, congratulations on the release of icecast 2.1.0 I presume this is the right place to post about iceS. please correct if wrong. I have a two instance setup, and have been finding that after a network error occurs, the instance does not reconnect. The source server is behind a linux NAT box. I have simulated the problem by using iptables REJECT with tcp-reset and here is the

hi everyone! currently, karl's branch of ices has a number of interesting features that the ices release does not: * jack support (very important for a number of users i know, and generally cool in terms of interoperability) * really nice metadata updates and on-the-fly savefile changes * runner threads for load distribution on smp boxen * on-the-fly switching of input sources (useful

On Wed, Nov 24, 2004 at 07:26:27PM -0600, Keith Whyte wrote: > I have a two instance setup, and have been finding that after a network > error occurs, the instance does not reconnect. > > The ESTABLISHED connection is the instance which didn't get blocked by > iptables. > and those sockets seem to remain in CLOSE_WAIT until i kill the ices > process. This sounds

On Sun, Feb 20, 2005 at 08:15:42PM +0000, Karl Heyes wrote: > setting <logsize> will cause an automatic log rotation when a certain > file size has been reached. It renames <logfile> to <logfile>.1 then > opens a new file <logfile> Since all my other logs are rotated on a daily/weekly basis, I want my ices logs to behave in the same way. Nevertheless, this thread

Fr?d?ric Bri?re wrote: > Hiya Karl (and everybody else), hi > I noticed today that ices 2.0-kh60a came out last January, and opted to > give it a try. Unfortunately, it just wouldn't work at all, so I had to > back down to 2.0-kh60. ok, send me your xml, so I know what parts are being used, I have to check the code for something else, but it does look to be the libshout part

On Mon, 2004-10-18 at 16:06, Andy Baxter wrote: > I've been having a problem where ices-kh (the jack'ified version) > disconnects from its jack input source unexpectedly. This happens mainly > while other jack clients are being started/stopped, or > connected/disconnected, but also at other times (e.g. switching between > different X sessions). I'm planning to do a bit

Andy Baxter wrote: > I've been having a problem where ices-kh (the jack'ified version) > disconnects from its jack input source unexpectedly. This happens mainly > while other jack clients are being started/stopped, or > connected/disconnected, but also at other times (e.g. switching between > different X sessions). I'm planning to do a bit more work on tuning up the

On Mon, 18 Oct 2004 16:06:00 +0100, Andy Baxter wrote: > I've been having a problem where ices-kh (the jack'ified version) > disconnects from its jack input source unexpectedly. This happens mainly > while other jack clients are being started/stopped, or > connected/disconnected, but also at other times (e.g. switching between > different X sessions). I'm planning to do

On Mon, 2004-11-01 at 03:23, andy wrote: > I just had a look at it and it's still dropping ports - I set a test > running which has ices-kh running from an ecasound process which is > connected to a new source every 10 minutes, and after about 3 hours it had > lost the jack port connection to ecasound. Can you send me the full log? > 2004-11-01 01:28:09] DBUG

On Mon, 18 Oct 2004 16:15:44 +0100, EvilOverlord wrote: >> The setup I'm working with is an ecasound session relaying audio between >> its input and output ports, with its output connected to all the ices >> clients for the different streams we're running. Then I'm >> switching the ecasound input between different stream sources (line in, >> recorded

On Mon, 2004-10-18 at 21:04, Jack O'Quin wrote: > > > > > > There are several ways to gain realtime privileges. Running as root > > > is the simplest, but perhaps the worst solution. > > > > Just to be clear, with ices, you can drop to a nominated user after the > > realtime scheduler is selected. Running as root after that is not > >

Karl Heyes <karl@xiph.org> writes: > Are you running with realtime privileges, for this you need to start as > root if you want that. Even with realtime privileges there may be odd > cases where the scheduling latency is a bit too high, it all depends on > the drivers and kernel version but the current state is not that bad and > getting better. There are several ways to

On Mon, 2004-10-18 at 22:14, Paul Davis wrote: > jackd (realtime) requires various resources which it shares with its > clients: > > realtime scheduling > mlock-ability > shared memory segments > FIFOs (or Mach ports on OS X) > > we consider it *more* of a security risk to allow jackd-as-root to > share these with non-root processes. YMMV.

Karl Heyes <karl@xiph.org> writes: > On Mon, 2004-10-18 at 18:27, Jack O'Quin wrote: > > Karl Heyes <karl@xiph.org> writes: > > > > > Are you running with realtime privileges, for this you need to start as > > > root if you want that. Even with realtime privileges there may be odd > > > cases where the scheduling latency is a bit too

>I can't really comment on jackd itself, as I haven't looked that much >into it. If running jackd as root requires client apps to also run as >root then that is a pretty bad issue. I would of thought that running >jackd as a realtime process (whether root or not) would be an important >consideration. jackd (realtime) requires various resources which it shares with its