[icecast] Ices re-encodes have died

Tue Mar 9 16:17:40 UTC 2004

Hi:

I'm running ices on one box with three streams, one streaming as is and two
re-encodes, and another box running icecast2.

The straight-through stream is going strong, but the two re-encodes have
died.  Ices is trying to re-establish them, but it keeps saying it gets a
broken pipe, as evidenced below:

[2004-03-09  10:47:55] INFO encode/encode_initialise Encoder initialising
in VBR mode: 2 channel(s), 44100 Hz, quality 0.000000
[2004-03-09  10:47:56] EROR stream/ices_instance_stream Send error: Socket
error (Broken pipe)
[2004-03-09  10:47:56] DBUG input/input_flush_queue Input queue flush
requested
[2004-03-09  10:47:56] WARN stream/ices_instance_stream Trying reconnect
after server socket error
[2004-03-09  10:47:56] EROR stream/ices_instance_stream Send error: Socket
error (Broken pipe)
[2004-03-09  10:47:56] DBUG input/input_flush_queue Input queue flush
requested
[2004-03-09  10:47:56] WARN stream/ices_instance_stream Trying reconnect
after server socket error
[2004-03-09  10:47:57] INFO stream/ices_instance_stream Connected to
server: linux-speakup.org:9000/egoplay24.ogg
[2004-03-09  10:47:57] DBUG input/input_flush_queue Input queue flush
requested
[2004-03-09  10:47:57] INFO stream/ices_instance_stream Connected to
server: linux-speakup.org:9000/egoplay64.ogg
[2004-03-09  10:47:57] DBUG input/input_flush_queue Input queue flush
requested

and this cycle repeats.

There's not much of help in the icecast error log.  I had to grep for
"source" because of all the YP activity (see below), but it seems as if
ices isn't sending anything down the line.

[2004-03-09  10:47:56] INFO connection/_handle_source_request Source
logging in
at mountpoint "/egoplay24.ogg"
[2004-03-09  10:47:56] INFO connection/_handle_source_request Source
logging in
at mountpoint "/egoplay64.ogg"
[2004-03-09  10:47:57] DBUG source/source_main Source creation complete
[2004-03-09  10:47:57] DBUG source/source_main Source creation complete
[2004-03-09  10:48:07] WARN source/source_main Disconnecting source: socket
timeout (10 s) expired
[2004-03-09  10:48:07] INFO source/source_main Removing source following
disconnection
[2004-03-09  10:48:07] INFO source/source_main Source "/egoplay24.ogg"
exiting
[2004-03-09  10:48:07] WARN source/source_main Disconnecting source: socket
timeout (10 s) expired
[2004-03-09  10:48:07] INFO source/source_main Removing source following
disconnection
[2004-03-09  10:48:07] INFO source/source_main Source "/egoplay64.ogg"
exiting

Note that I don't think the two clocks are sinched, so don't try to align
the two sets of times.

The access log is even less helpful.

129.100.249.144 - - [09/Mar/2004:10:43:50 -0500] "SOURCE /egoplay24.ogg
HTTP/1.0" 200 19 "-" "IceS 2.0-Beta4" 11
129.100.249.144 - - [09/Mar/2004:10:43:51 -0500] "SOURCE /egoplay64.ogg
HTTP/1.0" 200 19 "-" "IceS 2.0-Beta4" 12
129.100.249.144 - - [09/Mar/2004:10:48:07 -0500] "SOURCE /egoplay64.ogg
HTTP/1.0" 200 19 "-" "IceS 2.0-Beta4" 11
129.100.249.144 - - [09/Mar/2004:10:48:12 -0500] "SOURCE /egoplay24.ogg
HTTP/1.0" 200 19 "-" "IceS 2.0-Beta4" 16
129.100.249.144 - - [09/Mar/2004:10:51:38 -0500] "SOURCE /egoplay24.ogg
HTTP/1.0" 200 19 "-" "IceS 2.0-Beta4" 10
129.100.249.144 - - [09/Mar/2004:10:51:38 -0500] "SOURCE /egoplay64.ogg
HTTP/1.0" 200 19 "-" "IceS 2.0-Beta4" 10

Unfortunately, I don't have the ices log for when the problem started.  For
some hither-to unknown reason, the ices log starts at just before 19 hours
on Sunday, by which time this had already started.

I'm running ices 2.0beta4 from Debian Unstable, along with libogg 1.1 and
libvorbis 1.01 packages.  Libshout is 2.0, also in Debian Unstable.

I'm also running icecast 2.0 (compiled from source) with GCC 2.95.4,
against libogg 1.1 and libvorbis 1.01 (both compiled from source), and
libcurl 7.10.5 (also compiled from source).  This is running on a Debian
3.0 (aka Woody) system.

Another, quite likely unrelated question, is that the YP stuff seems to be
doing a hell of a lot.  at one stage, I could see only 2 seconds worth of
activity on the screen, with all the YP debug stuff.  Is there some
specific delay time between YP touches?  I do of course realise that ices
trying to reconnect may be causing this and not the other way around, it's
just that there's nothing in the icecast config that defines how often to
touch the YP servers (at least as far as I can see).  I've been running the
server since Saturday and the error log is 61.3 meg.

Any help with either would be appreciated.

Geoff.

<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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.