Live data from Hacker News

Fastpotify

fastpotify.rocks

421–430 of 583 posts

Re: Fastpotify

#421
post #238

Spotify is, without doubt, the worst piece of software that I still use on a daily basis. It's incredibly buggy, incredibly slow, and the UI has so many "usability inconsistencies". I find the Android app particularly bad, just a couple of examples: - Under a playlist you get a list of suggested songs, the UI element looks like a "regular song", but unlike every other "song" element the user has been trained to recog…

The whole service is shit, all music you discover is bought to be there, a lot of it is AI.

Re: Fastpotify

#422
post #210

Earlier quoted context omitted.

> I feel like if you can’t be bothered to write the code, at least document it yourself and write the marketing copy so I know you understand the product. Do you not understand it? This person doesn't owe you any work. He's providing a product for free and this is a reasonable enough description of the product. > Did the LLM generate some amazing rm -rf somewhere, or another blunder that wrecks data I might care abou…

> This person doesn't owe you any work. He's providing a product for free A product being free doesn’t make it exempt from criticism. It’s not about “owing” anybody work. > and this is a reasonable enough description of the product. It’s not a great idea to signal a lack of effort, nor is it wrong for users to pick up on that signal. This is the post-llm equivalent to spelling or grammatical errors. > I'm pretty sure…

> A product being free doesn’t make it exempt from criticism. It’s not about “owing” anybody work.

You can criticize it but your criticism is hallow

> It’s not a great idea to signal a lack of effort, nor is it wrong for users to pick up on that signal. This is the post-llm equivalent to spelling or grammatical errors.

Why should you put in effort to something that should be effortless? Why should I waste my time writing some inferior copy by hand?

> LLMs produce code which is fairly ‘locally optimal’, so in good hands they can absolutely be used to build correct software.

Humans produce code which is fairly ‘locally optimal’

Also, interesting you use ‘ as a quote rather than '. I notice these quotes are used with LLM generated text, as I can't find this on my keyboard.

Re: Fastpotify

#423
post #214

Earlier quoted context omitted.

What makes you think Spotify is killing it? I know they aren't supporting FLAC but otherwise I don't think they're actively trying to stop it as opposed to not really caring if they support it (which is more "We don't care" as opposed to "We have to stop this")

Author here. I haven't seen any evidence of Spotify killing librespot. To me the project looks active and works totally fine. I don't have a new Spotify account to verify the claim above. I suspect wilted-iris is conflating it with the recent changes to the Web APIs: new developer apps can't use all endpoints anymore. In Fastpotify if you add your Client ID I use both an older developer app and your app to keep every…

Have a look at the librespot pinned issues, you’ll see the reports from folks experiencing this. You may also be able to find the legal threats they sent out to third party client libraries if you search carefully (many have been redacted.)

Re: Fastpotify

#424

Earlier quoted context omitted.

The problem is not the emittance of code by a statistical black box. It’s not even knowing how it works or even what it used to achieve the desired result. You wrote it or not, that’s your code. You are the one responsible. The machine has no brain. Use yours.

That may be, but if I come back to the old project I didn't touch in months, code may as well be written by an alien.

I can return to my 5+ year old code and start hacking in 30 minutes or so. I believe it boils down to documentation and comments.

Re: Fastpotify

#425

Earlier quoted context omitted.

Can you list your exact complaints? It's a GUI like any other.

Alright I downloaded the thing, just for you. * Right off the bat in the login screen, if you resize the window, it flickers * I logged in. Double clicking the top part of the window doesn't maximize it, like I expect on basically all other windows. I'm using MacOS, btw * Resizing the main home screen is also a flickery mess. Though I'll give credit, it's a fast flickery mess, because the official spotify app resizes…

This seems like more of a complaint about egui's choice to re-implement all the widgets from scratch than its choice to use an immediate mode API. The two are orthogonal. The IMGUI idea has its roots in a community of people that like implementing things from scratch, but you could implement it on top of native widgets if you wanted to.

The choice to re-implement native widgets from scratch is justifiable if the egui devs think they can do better than the native widgets do. It's also nearly required in practice if they want the toolkit to have consistent behavior across multiple platforms (something people have learned the hard way multiple times across multiple different UI libraries).

It's hard to get it right, but that's why the egui devs are writing a library: so that others can benefit from that hard work. Many of the things you pointed out are just bugs, and bugs can be fixed.

Re: Fastpotify

#426
post #398

Earlier quoted context omitted.

Those numbers only look good in comparison.

I don't see you publishing something which further reduces the memory footprint? Given the project is open source, have at it! See if you can help improve it instead of complaining. This is a significant improvement and a cool project!

I'm not complaining and it is a cool project (from what I can tell). But I think it's fair to say 200 MB memory usage is a lot without providing source code as a proof. Just by feel when you recall what were computers capable of when they did not have 100s of MB to spare.

Re: Fastpotify

#427
I recently went through most of the Spotify clients I could find on GitHub, looking for something "lean", including screen real estate.

Most of the GUI apps had something similar to the official app in the maximized window, but none had a good mini-player, something I could put in the corner of an external monitor and control most of the important functions with minimal mouse clicking, including EQ and playlist.

Interestingly this one with its Winamp mode is what I was looking for. Nostaliga is probably playing a part, but it a good UI does not have to be "modern".

I also went through a tour of TUI apps. Lots of interesting work there, but a full TUI with windows was less convenient to navigate, and some of them try to do too much. I wound up using https://github.com/hrkfdn/ncspot because it specifically does not attempt to be a character mode GUI. Almost like a ViMusic.

Re: Fastpotify

#428

I might be misremembering, but I swear when Spotify launched it was a big revelation at the time because the client was super fast and playback was almost instantaneous. This was a big deal as other music players like iTunes were bloated. Obviously streaming was the big selling point, something that iTunes didn’t offer at the time, but I swear the client was written in some native UI framework, along with the C/C++ l…

I found a talk with some history of the Spotify client's transition:

https://www.youtube.com/watch?v=9UsnX5X_DF0

It was originally native, then native with some web-based bits, and then the web-based bits slowly ate the whole thing. It seems the ease of development with web-tech compared to C++ (also the better font rendering and screen reader support) was just too tempting.

Interestingly the Spotify client was never based on electron but instead arrived independently at the "chromium + web app" architecture at around the same time as Atom did.

Re: Fastpotify

#429

Earlier quoted context omitted.

As a matter of interest, would seeing a full disclosure that vibe coding was used sway your decision one way or the other?

Yes, a project maintained and built over longer time has a bigger chance of staying relevant, than someone's weekend fun they will abandon once the dopamine hit of "making something" wears off.

Isn't software written by hand more likely to be abandoned due to the extremely costly nature of keeping its development going? Abandonware definitely existed prior to vibe coding. As long as it's open source, now you can pick it up and keep vibe-developing it if you care to, for very little money/effort.
Post reply on HN