I have done some tests on the problem I keep having (as well as others) on the connection problem. Here's the message I get when i tail the logfile on the console at debug level 3 : -> [28/Feb/2001:11:58:54] Kicking client 13 [192.168.1.21] [Too many errors (client not receiving data fast enough)] [listener], connected for 21 minutes, 19906336 bytes transfered. 0 clients connected ->[28/Feb/2001:11:58:54] DEBUG: Removing connection 13 of type 0 -> [28/Feb/2001:11:58:54] DEBUG: Closing fd 12 The tests I've done in-house were with winamp as a client, and the following server/streamer combinations : icecast 1.3.0/shout 0.8.0 icecast 1.3.7/shout 0.8.0 icecast 1.3.8b2/shout 0.8.0 icecast 1.3.8b2/ices 0.0.5 All of these give the same perceived problem and the same error in the log. The connection between client and server is a dedicated leased line with a 512 kbit bandwidth. The streams themselves are all 128 kbit; since I use about 128 KB buffering, network problems shouldn't be an issue here. I'd like to set up some general testing with other users to track down where the problem is coming from. I'm thinking doing the same standardized test, with different server setups, with different network setups, and different clients. Right now I'm led to believe that the problem is somewhere between the icecast server and the client. I've also tried sonique as a client and it seems to have the same problems at first glance. I'm just taking a guess here, but maybe somewhere along the line the winamp client is expecting 128000 bits per second and icecast is sending out 128kbit per second, or something to that effect ? Does anyone know how this error is caused, why a client wouldn't receive data fast enough (as I would think it would take as much as it needs to play the stream each time), and why that really should be a problem anyway ? Thomas <-*- -*-> If you can call this luck if you can call this love if you can miss this much <-*- thomas@apestaart.org -*-> URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/ --- >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 am pretty sure that the integrity of my mp3's is okay. I know that music match shreds the mp3 data and produces mp3 files that are not ISO compliant. I always use WaveLab and the radium codec to encode my sets and enable the ISO compatibility option at all times. This problem only seemed to come about with winamp 2.7 but if sonique is doing it to, I don't know... What about relaying? Do streams get dropped in a similar manner in relay setup? If so then it would be network code or the network itself related. All of my test were done over the lan or locally on the same box using a duplicate instance of winamp to tune into the server and produced the same results. When done over the net served off of cable, to Palo Alto and back to Vancouver, Canada on my ADSL modem I got the same problem happening around the same time... If XMMS is not doing it then this leads me to believe that either the networking code in winamp 2.7 is shot (again) or it's the new decoder engine over 2.64 cause I never had this kind of problem with that version and used the same mp3 files for streaming then and now encoded with ISO compatibility. Just trying to eliminate some possibilities here... Lithium ----- Original Message ----- From: "Thomas Kirk" <thomas@arkena.com> To: <icecast@xiph.org> Sent: Wednesday, February 28, 2001 3:46 AM Subject: Re: [icecast] connection problem> Hey there again > > On Wed, Feb 28, 2001 at 12:16:12PM +0100, Thomas Vander Stichele wrote: > > > > The tests I've done in-house were with winamp as a client, and the > > following server/streamer combinations : > > icecast 1.3.0/shout 0.8.0 > > icecast 1.3.7/shout 0.8.0 > > icecast 1.3.8b2/shout 0.8.0 > > dont use shout! its buggy use ices or use libshout > > > icecast 1.3.8b2/ices 0.0.5 > > another thing could be your mp3s? Have you checked their integrity? Itsvery> important that they are 100% right go and fetch mp3check from freshmeat or > some other tool that will test their quality. Use cdparanoia when you rip > and lame when you encode. > > > > -- > Venlig hilsen/Kind regards > Thomas Kirk > thomas@arkena.com > http://www.arkena.com > > > It isn't necessary to have relatives in Kansas City in order to be > unhappy. > -- Groucho Marx > > --- >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. >--- >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.
> Hey there again > > On Wed, Feb 28, 2001 at 12:16:12PM +0100, Thomas Vander Stichele wrote: > > > > The tests I've done in-house were with winamp as a client, and the > > following server/streamer combinations : > > icecast 1.3.0/shout 0.8.0 > > icecast 1.3.7/shout 0.8.0 > > icecast 1.3.8b2/shout 0.8.0I don't know what it is that causes shout not to work for other people. I have 12 instances of shout 0.8.0 running for 45 days straight without any single problem. All the problems I ever have had with icecast seem to have been on the client side. Anyway, even in this setup there is no difference between the version with shout or with ices. I can believe there are people having problems with shout, but for me it works perfect at the moment. The people that are actually using the streams in production haven't complained for two months, so ...> another thing could be your mp3s? Have you checked their integrity? Its very > important that they are 100% right go and fetch mp3check from freshmeat or > some other tool that will test their quality. Use cdparanoia when you rip > and lame when you encode.The mp3's are created from 192 kbit mpeg-layer 2 mixes made by a program of mine which are then fed to mpg123 to go to the sample domain and then back to lame. So I'm pretty sure they're ok. That's one thing I should have mentioned as well : I'm streaming mp3's lasting 2 hours. Is it possible that media player can detect this or not ? Thomas <-*- -*-> Follow me down to the bushes dear No one will know we'll disappear I'll hold your hand we'll never tell Our private little trip to hell tonight <-*- thomas@apestaart.org -*-> URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/ --- >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.
Hey there again On Wed, Feb 28, 2001 at 12:16:12PM +0100, Thomas Vander Stichele wrote:> The tests I've done in-house were with winamp as a client, and the > following server/streamer combinations : > icecast 1.3.0/shout 0.8.0 > icecast 1.3.7/shout 0.8.0 > icecast 1.3.8b2/shout 0.8.0dont use shout! its buggy use ices or use libshout> icecast 1.3.8b2/ices 0.0.5another thing could be your mp3s? Have you checked their integrity? Its very important that they are 100% right go and fetch mp3check from freshmeat or some other tool that will test their quality. Use cdparanoia when you rip and lame when you encode. -- Venlig hilsen/Kind regards Thomas Kirk thomas@arkena.com http://www.arkena.com It isn't necessary to have relatives in Kansas City in order to be unhappy. -- Groucho Marx --- >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.