[icecast] icecast2 connect / reconnect

[oddsock]

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

oddsock
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
>said here.
>
>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
>bug.
>
>Michael
>
>--- >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.