similar to: Is something wrong with ices 2.0-kh60a?

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

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

Hi Karl, I just tried the latest - same problem :( One of the lines in the log file seems interesting - see the (Out of memory) error.. After that appears it seems to never want to connect after that. My box has plenty of memory - ices seems to only use 30 megs of memory and around 29% cpu. Memory leak maybe? [2003-10-12 17:29:40] EROR om_shout/output_ogg_shout Failed to write to

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 source package or the deb at /usr/share/doc/ices2-kh/ i

G'day Karl, I've been using your multiple instance version ices-2.0-kh43 for live streaming from my soundcard. After about 24 hours, connection to my icecast server is lost - checking my netstat I see that the connection is in "CLOSE_WAIT" status - this seems to stop it from being able to reconnect. Here is some sample ices.log output: [2003-10-09 06:57:17] DBUG

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

Hello, I had a problem with ices kh48 and icecastkh13. I usually restart them by cron at 00:00. ----------1---------- This night, icecast told ices "Too many sources" for radio-bro-gwened.ogg... All right, I've just seen that my config file is wrong for icecast (I have 3 sources): <sources>2</sources> But, with this configuration, I can have 3 sources:

Hello, ices kh48 seems to have some trouble... See the stranges characters avec metadata update. (before, it was written bad address) and also, it is not connecting to icecast: socket error, ... I go back to kh47 for the moment. Chris [2003-11-25 10:45:50] INFO ices-core/main Streamer version IceS 2.0-kh-pre48 [2003-11-25 10:45:50] INFO ices-core/main libshout version 2.0-kh22 [2003-11-25

Hello, I will take your last version, but I have fresher news about the bug that occurs every mornings in fact... I think this is ntpdate which is causing the problem, as the time of the machine change for more than one second. Here is all the info: 09:46:17 up 1 day, 1:22, 2 users, load average: 0.60, 0.71, 0.68 86 processes: 84 sleeping, 2 running, 0 zombie, 0 stopped CPU states: 10.4%

Package: logcheck Version: 1.2.39 Severity: normal Since I've upgraded my servers to sarge, I'm getting mail every hour for stuff that was duly included in /etc/logcheck/logcheck.ignore. Turns out that sarge's version no longer reads that file. If this was a conscious decision, then there should be some warning about this when upgrading (via debconf of NEWS.Debian). Also, the

On Fri, 2003-10-10 at 04:51, Matt Trim wrote: > G'day Karl, > > I've been using your multiple instance version ices-2.0-kh43 for live > streaming from my soundcard. well it's multiple input really but... > After about 24 hours, connection to my icecast server is lost - checking > my netstat I see that the connection is in "CLOSE_WAIT" status - this seems

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

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

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

Package: logcheck-database Version: 1.2.61 Severity: wishlist File: /etc/logcheck/ignore.d.server/proftpd Two weeks ago, I got a rush of these: Sep 8 12:37:07 goretex proftpd: PAM-listfile: Refused user news for service proftpd (Apparently, fail2ban managed to miss those.) This is triggered by pam_listfile, which is used by proftpd (and other FTP daemons) to block users listed in

Package: logtail Version: 1.2.68 Severity: normal Hi, logtail does not cleanly update from logtail2: $ sudo dpkg --install /var/cache/apt/archives/logtail_1.2.68_all.deb (Reading database ... 26564 files and directories currently installed.) Unpacking logtail (from .../logtail_1.2.68_all.deb) ... dpkg: error processing /var/cache/apt/archives/logtail_1.2.68_all.deb (--install): trying to

On Sun, 31 Oct 2004 22:32:17 +0000, andy wrote: > 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