indeed it does..nice work Mike :) oh, and am I not supposed to see my responses to the list ? I get all responses to my post, just not my original post, which is kind of disconcerting if I don't get any responses to a post...anyway, at least this bug is fixed... now if we could only get the server to send stream data out as fast as it can when a client first connects to eliminate the long buffer times when first attaching to a stream (which for low bitrates can be very long).. ;) oddsock At 06:56 AM 10/6/2002 -0400, you wrote:>i can confirm that this fixes the bug. > > >On Sun, 2002-10-06 at 06:12, Michael Smith wrote: > > At 09:29 PM 10/4/02 -0500, you wrote: > > >weird..I posted this a few days ago, but it never showed up... > > > > It did, I just didn't get around to looking at it in depth... > > > > > > > >anyway, here it is (again) :) > > >--------------------------------------------------- > > > > > >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.... > > > > This is triggered in some rare circumstances, and was worsened by a recent > > incorrect bugfix (there was a bug, the fix was wrong and exacerbated the > > problem, making it more likely to be triggered). > > > > I didn't fix it sooner because the vast majority of my files (and other > > test streams) don't trigger the bug anyway. I think this is the problem > > you and others have been seeing, so do an update and see if it's improved. > > > > Mike > > > > --- >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. >-- >http://chemlab.org - email shade-pgpkey@chemlab.org for pgp public key > chemlab radio! - drop out @ http://mp3.chemlab.org:8000 24-7-365 > >"i could build anything if i could just find my tools.." >--- >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.
i can confirm that this fixes the bug. <p>On Sun, 2002-10-06 at 06:12, Michael Smith wrote:> At 09:29 PM 10/4/02 -0500, you wrote: > >weird..I posted this a few days ago, but it never showed up... > > It did, I just didn't get around to looking at it in depth... > > > > >anyway, here it is (again) :) > >--------------------------------------------------- > > > >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.... > > This is triggered in some rare circumstances, and was worsened by a recent > incorrect bugfix (there was a bug, the fix was wrong and exacerbated the > problem, making it more likely to be triggered). > > I didn't fix it sooner because the vast majority of my files (and other > test streams) don't trigger the bug anyway. I think this is the problem > you and others have been seeing, so do an update and see if it's improved. > > Mike > > --- >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.-- http://chemlab.org - email shade-pgpkey@chemlab.org for pgp public key chemlab radio! - drop out @ http://mp3.chemlab.org:8000 24-7-365 "i could build anything if i could just find my tools.." --- >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 09:34 AM 10/7/02 -0500, you wrote:>indeed it does..nice work Mike :) > >oh, and am I not supposed to see my responses to the list ? I get all >responses to my post, just not my original post, which is kind of >disconcerting if I don't get any responses to a post...anyway, at least >this bug is fixed...You should (other people, like me, get our own posts). Not sure what's wrong.> >now if we could only get the server to send stream data out as fast as it >can when a client first connects to eliminate the long buffer times when >first attaching to a stream (which for low bitrates can be very long).. ;) >Technically, that's easy. There are as many reasons to NOT do that as there are reasons TO do it, though. Perhaps I'll make it optional when I next have time to do new-feature-type-work (late nov. or december). Mike --- >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.