[icecast] icecast2 connect / reconnect
oddsock at oddsock.org
Thu Oct 3 14:14:20 PDT 2002
while we are talking about disconnects, I'll mention the fact that
apparently when metadata song changes are done by a source (mine namely),
icecast2 seems to want to disconnect each listener. I have confirmed that
on metadata song changes, on the source client, no closing of the sockets
are done, only logical vorbis bitstream closings....
you can see this very clearly by using wget on a icecast2 vorbis stream,
and when my source client sends new metadata, wget exits immediately..so
this is telling me that icecast2 is definately closing the socket...most
people probably don't notice this much because I believe both winamp and
xmms will immediately try reconnect at least once, which succeeds (and has
the also unlikely effect of rebuffering many times)...
anyway, I would love to provide a patch for this for icecast2, as I am
currently swamped with work, but I thought I would at least mention it....
At 12:18 AM 10/4/2002 +1000, you wrote:
>At 12:41 PM 10/3/02 +0200, you wrote:
> >Michael Smith wrote:
> >> This looks like the two sources successfully connected, some clients
> >> then successfully connected to those sources, and then the sources
> >> disconnected later on. Where's the problem?
> >The problem is that the source does not intend to disconnect.
> >The whole setup is the following:
> >1. server machine, with both icecast 1.x and icecast2 installed
> >2. encoder, running one darkice instance, encoding 3 streams: two Ogg
> >Vorbis sent to the icecast2 server, one mp3, sent to the icecast 1.x server
> >each encoding session is supposed to last 4 hours.
> >in the setup above, both connections to the icecast2 server are dropped,
> >while the connection to the icecast 1.x is not. I can not think of any
> >other reason than icecast2 drops the connection.
>Ah. My confusion comes from your initial report, which said
>"these reconnects don't succeed", which directly contradicts what you
>I've had a look at the source. There was one possible (but very unlikely -
>it requires certain buffers to be exactly the right size at exactly the
>wrong time, as well as some other things happening simultaneously) bug,
>which I've now fixed. I also added extra debug-level log statements
>on source disconnect, which should tell you with a little more detail
>what the reason for the source disconnect was.
>If it now works reliably/correctly, then the obscure bug was indeed
>being triggered. If not, this is almost certainly a (source) client
>--- >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.
<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 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.
More information about the Icecast