Icecast - Aug 2004 - Problem with ices on OpenBSD 2.9 w/ Icecast 1.3.10

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.

Nick

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

On Tuesday, 10 July 2001 at 16:50, Nick Ludlam wrote:
> 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.
To confirm that this is the problem, stream a track from ices. ices
should take the same amount of time to stream that track as the track
is long. When it isn't sleeping properly, it finishes sending the
track to icecast much earlier.

If ices takes two minutes to send a two-minute mp3, you are having a
different problem.

-Brendan

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

hello,

i am quite new with icecast and ices and shout. i have just installed them three
days ago. i mainly tried ices instead of shout since it is much more
advanced. since v0.2 is supposed to be untested, i started with 0.1.
my problem is that ices just quits after some time (1-3 hours
normally). i am not really able to analyze what the problem is.

this is what icecast.log gives me:

[10/Jul/2001:07:14:40] [51:Source Thread] Kicking source 47 [localhost] [Lost
all clients to new source] [encoder], connected for 3>
[10/Jul/2001:07:14:40] [51:Source Thread] Kicking all 0 clients for source 47
[10/Jul/2001:08:33:59] [53:Source Thread] Lost connection to source on mount
/grooveomatic, waiting 30 seconds for timeout
[10/Jul/2001:08:34:29] [53:Source Thread] Kicking source 49 [localhost] [Client
timeout exceeded, removing source] [encoder], conne>
[10/Jul/2001:08:34:29] [53:Source Thread] Kicking all 0 clients for source 49

o obviously ices quits. however, when i listen to the stream myself
ices seems to be stable. i have tried that over a period of some
hours. ices always quits when it is in the background and nobody
listens to the stream it seems.
i have tried to pipe the debugging info with ices -c
configbla.conf
>mylog.log 2>&1
but this log turned out to be quite small with somehting like that:

Playing /home/mp3/Black Music/bobby brown - two can play that game.mp3
DEBUG: Filename cleaned up from [/home/mp3/Black Music/bobby brown - two can
play that game.mp3] to [bobby brown - two can play tha>
DEBUG: Updated metadata on grooveomatic to: bobby brown - two can play that game
DEBUG: D

my guess is that ices must´ve crashed or something, because there
should´ve been something useful and complete in this log, right ?

what are your ideas ? how can i do further monitoring ? i don´t
believe there is anything wrong with the config files.

regards,
Benjamin Zeiss                            mailto:bz@zeiss.net

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

From: "Brendan Cully"
<brendan@icecast.org>
> On Tuesday, 10 July 2001 at 16:50, Nick Ludlam wrote:
> > 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.
> 
> To confirm that this is the problem, stream a track from ices. ices
> should take the same amount of time to stream that track as the track
> is long. When it isn't sleeping properly, it finishes sending the
> track to icecast much earlier.
> 
> If ices takes two minutes to send a two-minute mp3, you are having a
> different problem.
Hurray! I found the problem, and it lies with icecast. If I set sleep_ratio
to 0, I get no problems with icecast reading data from the socket. I spent
a while working out that after a certain length of time, ices started falling
over
when the thread reading the socket in icecast wasn't waking up in time
so send() in ices started blocking.

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 sleep_ratio at
0 as this is prohibitively cpu-intensive. I guess this doesn't crop up when
running on Linux as the scheduler is different.

Nick

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