weird..I posted this a few days ago, but it never showed up... 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.... 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.... <p>oddsock <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.
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.
ugh. this is a showstopper.. is there any fix yet? i'm having the same issue. if i HUP ices, it doesn't cause my client to reconnect (the song changes and the metadata updates) but when it normally switches tracks, the stream ends. i also see "invalid password" messages in my error log.. <p><p>On Fri, 2002-10-04 at 22:29, oddsock wrote:> weird..I posted this a few days ago, but it never showed up... > > 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.... > > 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 > > > --- >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 12:40 AM 10/6/02 -0400, you wrote:>ugh. this is a showstopper.. is there any fix yet? i'm having the same >issue. if i HUP ices, it doesn't cause my client to reconnect (the song >changes and the metadata updates) but when it normally switches tracks, >the stream ends. i also see "invalid password" messages in my error >log..The 'invalid password' log messages are ok, but I think I'll change the way ices connects - at the moment, it tries to connect first without the password, then, if it gets a "401 Unauthorized", re-tries with the password. I think when I have some time I'll make it just always send the password, since there's not really any reason not to. I don't know what's causing some (but not most, or even many) people to see spurious disconnects from the server - I certainly don't see it in any of my local test setups. Current cvs (as of a couple of days ago) should log (at debug level) some additional information about why sources are being disconnected, when they are. So people having problems should update and see if that helps. 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.
Hi: We've started getting invalid/missing password problems too. They started suddenly on about Tuesday or Wednesday. We have 3 streams being served from the one ices instance, and often only one will be able to connect. I tried doing an update and recompiling everything, but that seems to have made things worse, as the one that did manage to reconnect got dumped too, leaving it chugging away with the data not going anywhere. Before I updated, the ices log was talking about broken pipes. Now it's inability to connect doesn't seem to be noted anywhere. Geoff. <p> -- Geoff Shang <gshang@uq.net.au> ICQ number 43634701 Make sure your E-mail can be read by everyone! http://www.betips.net/etc/evilmail.html Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html <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.