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. --- >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.
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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Michael Smith wrote:> Ah. My confusion comes from your initial report, which said > "these reconnects don't succeed", which directly contradicts what you > said here.I don't see the contradicition, but never mind.> If it now works reliably/correctly, then the obscure bug was indeed > being triggered. If not, this is almost certainly a (source) client > bug.Thanks for the fix. I'll apply it the next time things break.. <p>Akos --- >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.
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@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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.