Icecast - Aug 2004 - darkice problems (was Re: Propping up liveice)

I'm a volunteer who runs the mp3 streaming for KGNU-FM in Boulder, 
Colorado.  We stream live at 64K with Linux, icecast 1.3.12+ minor 
patches, liveice, and lame 3.92.  It easily supports 32 internet 
listeners 24x7 from a donated 400MHz Pentium II.

Liveice is the only problem--it does its job of connecting the soundcard 
rec in to the lame encoder and to icecast, but dies without explanation 
on the average of every couple weeks.  I tried darkice, but it doesn't 
deal with lame correctly.  So I wrote a script to resurrect liveice when 
needed.  It is very specific to our setup, because it expects a certain 
number of process ids (threads) to be there.  Root runs this every five 
minutes via cron like this:
*/5 * * * * /usr/local/icecast/bin/check_icecast

We now average about 60 seconds of downtime a month, and I can leave the 
server totally unattended.  I hope this is of use to someone else, and I 
welcome any suggestions.  Here's the script:

#!/bin/sh
#
# check_icecast
#
# This script ensures that icecast, liveice, and lame are alive, and
# restarts them if they're not.  It checks for an expected number of
# process ids owned by "nobody".  If those aren't found, it kills
any
# stragglers and runs the appropriate startup script.  It uses pgrep
# (find process by wildcard) and wc (word count).
#
# If everything looks alive, this script outputs nothing.  Otherwise,
# it reports what had to be restarted and when.  This script is
# intended to be run often via cron.
#
# TODO: It's possible that all the processes are alive, but that the
# liveice source has become disconnected from the icecast server
# somehow.  We need a way to check for this condition, too.

LIVEICE_PIDS=`pgrep -u nobody 'liveice|lame'`
LIVEICE_PIDNUM=`echo $LIVEICE_PIDS | wc -w`
ICECAST_PIDS=`pgrep -u nobody 'icecast'`
ICECAST_PIDNUM=`echo $ICECAST_PIDS | wc -w`

if [ "$ICECAST_PIDNUM" -lt "6" ] ; then
    kill -9 $LIVEICE_PIDS $ICECAST_PIDS >/dev/null 2>/dev/null
    sleep 5
    cd /usr/local/icecast/bin
    su nobody -c ./start_streaming
    echo "icecast restarted at `date`"
    renice -1 `pgrep -u nobody 'liveice|lame|icecast'`
else
    if [ "$LIVEICE_PIDNUM" -lt "3" ] ; then
        kill -9 $LIVEICE_PIDS >/dev/null 2>/dev/null
        sleep 5
        cd /usr/local/icecast/bin
        su nobody -c ./start_liveice
        echo "liveice restarted at `date`"
        renice -1 `pgrep -u nobody 'liveice|lame'`
    fi
fi

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Matt Boersma wrote:
> on the average of every couple weeks.  I tried darkice, but it doesn't 
> deal with lame correctly.  So I wrote a script to resurrect liveice when 
Could you elaborate on this? In what respect does darkice not deal with 
lame correctly?

<p>Akos

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

lundi 27 mai 2002, 07:27:32, Akos Maroy a écrit :
> Matt Boersma wrote:
>> on the average of every couple weeks.  I tried darkice, but it
doesn't
>> deal with lame correctly.  So I wrote a script to resurrect liveice
when
> Could you elaborate on this? In what respect does darkice not deal with 
> lame correctly?
Personnally I have those error messages repeting with darkice :
"Internal buffer inconsistency. flushbits <> ResvSize"

According to what I found on the Net this looks like a Lame bug,
espescially when Lame is used with the -h option (removing it solved the
problem in LiveIce).


-- 
Ced                           

<p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

I tried darkice 0.9 with icecast 1.3.12 and lame 3.91.  I specified a 64k 
stream and similar options to what works for us with liveice.

Streaming worked successfully, and I applaud darkice for being fairly 
simple to build and configure.  But the stream sounded like mud.  It was 
worse than our 16k mono RealAudio stream.  I re-examined my config, I 
rebuilt everything with gcc 2.96, then with gcc 3.01, with no compiler 
opts, with some agressive ones, and even tried a prebuilt Mandrake RPM for 
lame, thinking that darkice's interfacing with the lame shared lib might 
have been a problem.  But no luck--it still sounded horrible.

I then consulted this newsgroup's archives and did some googling and found 
a couple references that implied that darkice was now more focused on 
icecast 2 support and now had broken lame support for icecast 1.x.  I 
assumed that was my problem.  I thought about building an older 
darkice--maybe 0.5 or whichever was the last one *not* to require lame as 
a shared lib--but had already put too much effort into it.

If other folks have it working correctly for a 24x7 live 64k stream 
against iceast 1.3.12, I'm all ears.

-Matt

<p>On Sunday, May 26, 2002, at 11:27  PM, Akos Maroy wrote:
> Matt Boersma wrote:
>> on the average of every couple weeks.  I tried darkice, but it
doesn't
>> deal with lame correctly.  So I wrote a script to resurrect liveice
when
>
> Could you elaborate on this? In what respect does darkice not deal with 
> lame correctly?
>
>
> Akos
>
>
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> icecast project homepage: http://www.icecast.org/
> To unsubscribe from this list, send a message to 'icecast-
> request@xiph.org'
> containing only the word 'unsubscribe' in the body.  No subject is
needed.
> Unsubscribe messages sent to the list will be ignored/filtered.
>
<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.