I'm listening to "Internet Radio" quite a lot these days, and foobar2000 has recently become my favored player of choice. There are several streams hosted my http://www.somafm.com that I enjoy, a few of which tend to stall, and a few of which don't. I was wondering if this behavior was due to a behavior on the somaFM stream server's side of things, or foobar2000's. I don't know enough about foobar2000 to get any useful sort of debug output (I could fire up ethereal, if warranted) but I was hoping some other people could try these URLs and see if they get similar results - and maybe give me some tips.

Streams (in decreasing order of how likely they are to crap out):
http://somafm.com/dronezone.pls (frequently)
http://somafm.com/indiepop.pls
http://somafm.com/cliqhop.pls

It seems like a buffering (or lack thereof) thing, so maybe ways of increasing the rate at which foobar2000 replenishes said buffer would be good? I'm open to ideas and general wisdom. All streams are 128kb/sec, my connection is a great deal more bandwidth.

Preferences/Networking/HTTP/Buffer size allows settings from 16KB to 16MB. Which settings have you tried?

I'm experimenting with it right now; trying to see if it makes any difference. I tried cranking it all the way up, and the stream appears to still stall on occasion; I'm going to try timing the stalls and see if there's any effect.

(Can anyone else give these a listen and try to replicate what I'm getting?)

After listening to that "http://somafm.com/dronezone.pls (frequently)" stream for more than 40 minutes without a single dropout (default buffer size of 256KB by the way), I seem to be unable to reproduce your problem.

Thanks for trying - I'll keep fiddling with it.

Are you sure that there weren't other applications hogging all your bandwidth?

Note that often a saturated upstream may negatively affect your downstream bandwidth as well.

Yeah - I'm on a campus LAN with plenty of headroom; the stall seems largely independent of other network usage on my part. I'm not putting it past the campus network to be screwing things up somehow, but I find it hard to believe it's only affecting one or two streams. Maybe one of our outgoing routes just plain sucks; I'll look into it.

The same happened to me today. I have never had such problems with 0.8.3 and kode54's foo_read_http. There is no option to set % of buffer to read-ahead on first play and % of buffer to read on underrun. Handling of buffer underruns is bad, I get 'flickering' sound. There is also a problem if I press seek key by accident. Playback stalls in this case. Sometimes I have to click several times on playlist entry to start playback, because foobar indicates 'opening...' in status bar but nothing happenes. It can be forever in 'opening...' state.

Edit: I'm using 1000KB buffer.

One more problem. If connection to server is lost during playback, foobar shows console with error message. Playlist item remains marked as playing. Itwould be much better to try to play next playlist item without popping up console with error message.

Preloading a settable amount of data before starting playback is in my opinion a good idea!

And one more problem. I often get something like this as a title:

Bumping this thread since the problem is still there in 0.9.4.1