4 ms·

I'd like to agree with you on that, and a year ago I would have done, but foobar2000 has some problems which, combined with its closed-source nature, have drive

by aaronem 13y ago

I'd like to agree with you on that, and a year ago I would have done, but foobar2000 has some problems which, combined with its closed-source nature, have driven me out of bed with it and back to the music-player equivalent of Match.com, with occasional late-night trips to the corner of YouTube and Audiobox.fm, when I'm looking to play something right now and can't find satisfaction anywhere else. I think that metaphor sort of got away from me toward the end. In any case, foobar2000's support for HTTPS streaming is lousy ranging to unusable; specifically, there is no mechanism, including the Windows CA certificate store, by which foobar2000 can be induced to accept a self-signed certificate as valid. When you can't stream music from home over your Comcast circuit without getting throttled because Comcast assumes MP3 data going upstream means BitTorrent, this poses a problem. There's also the problem of the playback queue not working the way it should. In theory, a playback queue is to a playlist as a lambda is to a named function; in practice, when foobar2000 reaches the end of a queue, it blithely continues playing tracks off the playlist whence came the last item in the queue, which is frankly ridiculous. I can understand from an implementation perspective why it works that way, but that doesn't make it any less broken. These are the reasons why I'm looking for a better music player. I wish I had any hope of ever finding one.

MichaelGG 13y ago
> Comcast assumes MP3 data going upstream means BitTorrent They actually scan TCP segments for MP3 headers or something?
- aaronem 13y ago
  I can only conclude they do that or something like it, based on the following observations: 1. When I stream MP3 content unencrypted from home to any other location, everything works well for up to the first half hour or so, and then packets start coming through so slowly as to result in about five seconds of buffering per second of music played. Once this starts to happen, I'm similarly unable to access, due to timeouts, any of the other services I host from home for my own use. If I stop MP3 playback and wait a couple of hours, the problem clears up, but only until I start streaming music again. 2. When I stream Ogg or FLAC content unencrypted &c., &c., I always get smooth playback for as long as I care to use it, and all my other home services work fine. 3. When I stream MP3 content via HTTPS &c., &c., I always get smooth playback for as long as I care to use it, and all my other home services work fine. Of further note: All the locations from which I've observed this problem offer sufficient downstream bandwidth to support streaming of 320Kbps CBR MP3 files, as indicated both by the fact that doing so over HTTPS works fine, and that streaming FLAC at much higher bitrates also works fine. I used to stream MP3 (but not FLAC) over Verizon DSL, which had barely enough upstream bandwidth to support it (and not enough for FLAC), and never had this sort of problem. The only variables in the admittedly informal tests I've run have been transport encryption and content encoding; in particular, all the content, regardless of format, comes from the same hardware, through the same HTTP server, across the same path through my local network. I suppose these observations might plausibly lead to some conclusion other than the one I've drawn, but I don't see how; if you do, I'd like to hear about it.
weland 13y ago
I don't listen to online radios much and when I do, mplayer handles the ones I like just fine, so this is an honest question: why on earth do you need to stream over HTTPS?
- aaronem 13y ago
  See my comments elsewhere in this thread for the detailed answer. The short version is that I'm streaming from home, and for some reason, if I do that with MP3-encoded content over an unencrypted transport, I can only get about a half-hour of playback at best before my packets start vanishing into the ether. Perhaps it's unreasonable of me to conclude this is because Comcast is throttling my traffic, but I used to do the same thing over Verizon DSL (whose upstream bandwidth was much more limited) and never had a problem, so...
  - weland 13y ago
    Got it. Thanks!
ANTSANTS 13y ago
>In any case, foobar2000's support for HTTPS streaming is lousy ranging to unusable; specifically, there is no mechanism, including the Windows CA certificate store, by which foobar2000 can be induced to accept a self-signed certificate as valid. When you can't stream music from home over your Comcast circuit without getting throttled because Comcast assumes MP3 data going upstream means BitTorrent, this poses a problem. This is a scenario where I wish foobar2000 was open source so this could be fixed independently, but have you tried mentioning this to the developer? Very few people are going to run into this problem, I think it's acceptable for them to miss this use case on the first try. As a last resort, I'm sure there's a plugin to transcode on the fly to vorbis or something. >in practice, when foobar2000 reaches the end of a queue, it blithely continues playing tracks off the playlist whence came the last item in the queue, which is frankly ridiculous. I can understand from an implementation perspective why it works that way, but that doesn't make it any less broken. It may seem broken to you, but to others it's useful functionality and the way I expect things to work. I use it all the time to queue up a certain album in a large playlist just by queuing the first track. Easier than selecting the whole thing, and I'd rather have something play when the album's done than be met by silence. If you double click a song to play it, it goes to the next song when it finishes. Why would making a short queue do anything different? Maybe there is a case for having an option for queues to work like you want, but frankly, this is yet another scenario where the existing tools work just fine to begin with. Make a new playlist and change to "Default" mode and it will stop playback after it completes. Unlike with the queue, which is only intended for short queues, you can easily order things however you like on the fly this way. There's something like a "UNIX philosophy" argument going on here: Most people agree that it's simpler to use text files for configuration instead of introducing a unique binary format with its own unique editor for every single program you might want to use. Similarly, I think it's simpler and more powerful to just work with the cheap and easy playlist primitive rather than try to hard-code everyone's special snowflake pet feature and getting a bloated, incomprehensible mess of a program. You can convince yourself you need all of these subtly different ways to group a bunch of songs together and always be in search of something more... or you can just make a playlist, which does the exact same thing if you squint a little, and be happy with just about any music player since Winamp. That it is closed source is a big problem to me, but if "not being able to stream over self-signed https connections" and "the queue mechanism is kinda different than I expected" are the biggest problems you have with foobar, you don't really have anything to complain about.
ubercow13 13y ago
I disagree with your point about the queue behaviour. If you want it to work like that, why not just use another playlist? The queue as it is actually complements the normal playlist-centric behaviour instead of being completely redundant. If you want it to work how you describe you can use this http://www.foobar2000.org/components/view/foo_stop_after_queue http://www.foobar2000.org/components/view/foo_stop_after_que...
- aaronem 13y ago
  Thank you for the link! I'd looked for something like that, but hadn't found it, and I greatly appreciate your cluing me in that it exists after all.

by aaronem 13y ago

MichaelGG 13y ago

> Comcast assumes MP3 data going upstream means BitTorrent They actually scan TCP segments for MP3 headers or something?

aaronem 13y ago
I can only conclude they do that or something like it, based on the following observations: 1. When I stream MP3 content unencrypted from home to any other location, everything works well for up to the first half hour or so, and then packets start coming through so slowly as to result in about five seconds of buffering per second of music played. Once this starts to happen, I'm similarly unable to access, due to timeouts, any of the other services I host from home for my own use. If I stop MP3 playback and wait a couple of hours, the problem clears up, but only until I start streaming music again. 2. When I stream Ogg or FLAC content unencrypted &c., &c., I always get smooth playback for as long as I care to use it, and all my other home services work fine. 3. When I stream MP3 content via HTTPS &c., &c., I always get smooth playback for as long as I care to use it, and all my other home services work fine. Of further note: All the locations from which I've observed this problem offer sufficient downstream bandwidth to support streaming of 320Kbps CBR MP3 files, as indicated both by the fact that doing so over HTTPS works fine, and that streaming FLAC at much higher bitrates also works fine. I used to stream MP3 (but not FLAC) over Verizon DSL, which had barely enough upstream bandwidth to support it (and not enough for FLAC), and never had this sort of problem. The only variables in the admittedly informal tests I've run have been transport encryption and content encoding; in particular, all the content, regardless of format, comes from the same hardware, through the same HTTP server, across the same path through my local network. I suppose these observations might plausibly lead to some conclusion other than the one I've drawn, but I don't see how; if you do, I'd like to hear about it.

weland 13y ago

I don't listen to online radios much and when I do, mplayer handles the ones I like just fine, so this is an honest question: why on earth do you need to stream over HTTPS?

aaronem 13y ago
See my comments elsewhere in this thread for the detailed answer. The short version is that I'm streaming from home, and for some reason, if I do that with MP3-encoded content over an unencrypted transport, I can only get about a half-hour of playback at best before my packets start vanishing into the ether. Perhaps it's unreasonable of me to conclude this is because Comcast is throttling my traffic, but I used to do the same thing over Verizon DSL (whose upstream bandwidth was much more limited) and never had a problem, so...
- weland 13y ago
  Got it. Thanks!

ANTSANTS 13y ago

>In any case, foobar2000's support for HTTPS streaming is lousy ranging to unusable; specifically, there is no mechanism, including the Windows CA certificate store, by which foobar2000 can be induced to accept a self-signed certificate as valid. When you can't stream music from home over your Comcast circuit without getting throttled because Comcast assumes MP3 data going upstream means BitTorrent, this poses a problem. This is a scenario where I wish foobar2000 was open source so this could be fixed independently, but have you tried mentioning this to the developer? Very few people are going to run into this problem, I think it's acceptable for them to miss this use case on the first try. As a last resort, I'm sure there's a plugin to transcode on the fly to vorbis or something. >in practice, when foobar2000 reaches the end of a queue, it blithely continues playing tracks off the playlist whence came the last item in the queue, which is frankly ridiculous. I can understand from an implementation perspective why it works that way, but that doesn't make it any less broken. It may seem broken to you, but to others it's useful functionality and the way I expect things to work. I use it all the time to queue up a certain album in a large playlist just by queuing the first track. Easier than selecting the whole thing, and I'd rather have something play when the album's done than be met by silence. If you double click a song to play it, it goes to the next song when it finishes. Why would making a short queue do anything different? Maybe there is a case for having an option for queues to work like you want, but frankly, this is yet another scenario where the existing tools work just fine to begin with. Make a new playlist and change to "Default" mode and it will stop playback after it completes. Unlike with the queue, which is only intended for short queues, you can easily order things however you like on the fly this way. There's something like a "UNIX philosophy" argument going on here: Most people agree that it's simpler to use text files for configuration instead of introducing a unique binary format with its own unique editor for every single program you might want to use. Similarly, I think it's simpler and more powerful to just work with the cheap and easy playlist primitive rather than try to hard-code everyone's special snowflake pet feature and getting a bloated, incomprehensible mess of a program. You can convince yourself you need all of these subtly different ways to group a bunch of songs together and always be in search of something more... or you can just make a playlist, which does the exact same thing if you squint a little, and be happy with just about any music player since Winamp. That it is closed source is a big problem to me, but if "not being able to stream over self-signed https connections" and "the queue mechanism is kinda different than I expected" are the biggest problems you have with foobar, you don't really have anything to complain about.

ubercow13 13y ago

I disagree with your point about the queue behaviour. If you want it to work like that, why not just use another playlist? The queue as it is actually complements the normal playlist-centric behaviour instead of being completely redundant. If you want it to work how you describe you can use this http://www.foobar2000.org/components/view/foo_stop_after_queue http://www.foobar2000.org/components/view/foo_stop_after_que...

aaronem 13y ago
Thank you for the link! I'd looked for something like that, but hadn't found it, and I greatly appreciate your cluing me in that it exists after all.