4 ms·
>In any case, foobar2000's support for HTTPS streaming is lousy ranging to unusable; specifically, there is no mechanism, including the Windows CA certificate s
by 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.
- aaronem 13y ago> As a last resort, I'm sure there's a plugin to transcode on the fly to vorbis or something. I'd have to do that on the server, which is plausible in theory, but would be an ugly mess when it came to FLAC/CUE-per-album stuff. I could also set up a VPN endpoint at home and connect to it from elsewhere, but it was easier just to find another player that doesn't get upset over self-signed SSL certs. (It seems to me that at least a rudimentary "do you trust this cert?" UI should be part and parcel of any HTTPS implementation, but I've never implemented an HTTPS client as such, so I suppose my opinion there is of suspect value.) As for the rest of your comment, have you read Richard Gabriel's "Worse is Better"? He makes some trenchant points about how the Unix philosophy you describe privileges implementation simplicity over interface simplicity, and if that makes life hard for the user, well, so be it; making life easy for the programmer is more important. Your argument here -- that it's entirely reasonable to require a lot of manual work in order to achieve perhaps a little more than fifty percent of the fashion in which I desire my music player to behave (the two problems you discount not being at all my only problems with the player) -- so transparently embodies the sort of thinking Gabriel decries, that I'm really confused as to whether you're doing it with a straight face. I waver between being so convinced, and believing instead that your comment is perhaps the single most subtly and delicately crafted example of satire that I have ever seen in my life. If the latter be true, then, sir, please accept my most profoundly sincere congratulations on having brought Dr. Swift's art to a new apotheosis. If the former, well, I suppose I can at least agree with you that it'd be nice if Pawlowski opened the source.
- ANTSANTS 13y agoJust noticed this reply, possibly the most eloquent way anyone has ever told me that they think I'm a moron. Yes, I've read Worse is Better. No, I don't think that the Unix philosophy is always the right one. I was 100% serious, though, no satire. On the contrary, I'm the one having a hard time believing the things people complained about in this thread. I mean, seriously? Make a new playlist and drag and drop the song into it vs. right click the song and hit "add to queue." I simply cannot believe that this is the kind of thing that would be a deal breaker for someone. If I may be so trite, it is a "first world problem" if ever there was one. "This program is perfect except for one minor detail; I don't care if there's a baby in it, this bathwater needs to be gone yesterday." One thing we might be able to agree on is the value of providing simple building blocks and a powerful but easy to use scripting interface. I think we could both learn to love the child of emacs and foobar, that would let you happily do whatever silly things you want to do with your queues while I remain none the wiser. In closing, to echo your passive aggressive tone, have heard this quote by Alan J. Perlis? "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." Perhaps the same could be said about programs that expose many different and separate interfaces for fundamentally similar problems.