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

On Tuesday, 10 July 2001 at 03:21, Nick Ludlam wrote:
> From: "Brendan Cully" <brendan@icecast.org>
> > That handles the segfault, I don't know why the stream
wouldn't be
> > sent fast enough though...
> 
> Tried with winamp, sonique and freeamp. All exhibit the same problem of
> stuttering play, and eventually this drops out of the icecast log:
> 
> -> [10/Jul/2001:03:04:57] Kicking client 14 [212.135.236.195] [Too many
errors (client not receiving data fast enough)] [listener],
> connected for 35 seconds, 257939 bytes transfered. 0 clients connected
> 
> and I know it's not bandwidth-based problems. This happens on a local
> network as well as my ADSL, both of which are good enough to stream
> at 12Kb/sec.
Ah, I found this one while playing with ices on solaris. The problem
seems to be a truncation error in libshout's timing/timing.c, in
timing_sleep, which results in ices not sleeping at all between
chunks. I hope you're experiencing the same problem, because I posted
a patch a couple days ago. Check out the CVS or wait for 0.2.1.
> > Of course ices hasn't had a proper security audit. Please check
with
> > Theo de Raadt before running it. :)
> 
> I'm bound to incur his wrath :)   Luckily my flatmate is a ports
maintainer
> so he gets most of the shouting. Someone else seems to be maintaining
good story :)
> icecast in the ports collection, but ices isn't, yet. Is ices here to
stay and
> icecast moving to icecast2? If that's the case, it might be worth
making
> a port of ices to complete the set.
icecast is moving to icecast 2, but ices isn't dead yet either. At
least, I plan to keep maintaining it.

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

From: "Brendan Cully"
<brendan@icecast.org>
> On Tuesday, 10 July 2001 at 03:21, Nick Ludlam wrote:
> > From: "Brendan Cully" <brendan@icecast.org>
> > > That handles the segfault, I don't know why the stream
wouldn't be
> > > sent fast enough though...
> >
> > Tried with winamp, sonique and freeamp. All exhibit the same problem
of
> > stuttering play, and eventually this drops out of the icecast log:
> >
> > -> [10/Jul/2001:03:04:57] Kicking client 14 [212.135.236.195] [Too
many errors (client not receiving data fast enough)]
[listener],
> > connected for 35 seconds, 257939 bytes transfered. 0 clients connected
> >
> > and I know it's not bandwidth-based problems. This happens on a
local
> > network as well as my ADSL, both of which are good enough to stream
> > at 12Kb/sec.
>
> Ah, I found this one while playing with ices on solaris. The problem
> seems to be a truncation error in libshout's timing/timing.c, in
> timing_sleep, which results in ices not sleeping at all between
> chunks. I hope you're experiencing the same problem, because I posted
> a patch a couple days ago. Check out the CVS or wait for 0.2.1.
Unfortunately I am using the CVS version. Is there any way for me to trace
where it's mistiming things?

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 14:10, Nick Ludlam wrote:
> From: "Brendan Cully" <brendan@icecast.org>
> > On Tuesday, 10 July 2001 at 03:21, Nick Ludlam wrote:
> > > From: "Brendan Cully" <brendan@icecast.org>
> > > > That handles the segfault, I don't know why the stream
wouldn't be
> > > > sent fast enough though...
> > >
> > > Tried with winamp, sonique and freeamp. All exhibit the same
problem of
> > > stuttering play, and eventually this drops out of the icecast
log:
> > >
> > > -> [10/Jul/2001:03:04:57] Kicking client 14 [212.135.236.195]
[Too many errors (client not receiving data fast enough)]
> [listener],
> > > connected for 35 seconds, 257939 bytes transfered. 0 clients
connected
> > >
> > > and I know it's not bandwidth-based problems. This happens on
a local
> > > network as well as my ADSL, both of which are good enough to
stream
> > > at 12Kb/sec.
> >
> > Ah, I found this one while playing with ices on solaris. The problem
> > seems to be a truncation error in libshout's timing/timing.c, in
> > timing_sleep, which results in ices not sleeping at all between
> > chunks. I hope you're experiencing the same problem, because I
posted
> > a patch a couple days ago. Check out the CVS or wait for 0.2.1.
> 
> Unfortunately I am using the CVS version. Is there any way for me to trace
> where it's mistiming things?
I guess you could put some printfs in shout_sleep and/or timing_sleep.
Could you first double-check that timing_sleep in
ices/libshout/timing.c looks like this:

void timing_sleep(long sleeptime)
{
        struct timeval sleeper;

        sleeper.tv_sec = sleeptime / 1000;
        sleeper.tv_usec = (sleeptime % 1000) * 1000;

        select (1, NULL, NULL, NULL, &sleeper);
}

and that you are not using an installed, older version of
libshout. ldd ices and check which libshout it is using. Ideally
libshout won't show up at all. You might try building
--without-libshout just to make sure.

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