Show HN: Lofi, a Tiny Spotify Player | Hacker News Reader

Show HN: Lofi, a Tiny Spotify Player

github.com

73 pointsdvt48 comments

Open articleView on HN

> a Tiny Spotify Player

Grab 80 Mbytes binary.[0]

[0] https://github.com/dvx/lofi/releases/tag/v1.6.1

Tiny in size, not footprint.

In readme[0] small footprint named as an advantage instead:

> Design goals

> ≤ 100MB memory footprint

[0] https://github.com/dvx/lofi#design-goals

So they met their stated design goal?

I remember when Puppy Linux's (on-disk) size limit was 50MB. There's a reason you don't use, "Is it tiny?" in twenty questions.

Cone on, the page makes it clear that “tiny” refers to the size and scope of the UI.

Ah it's a JS app because of course it is.

(don't hate me please, I write JS for a living and I need this job <_<)

From the FAQ:

> For Lofi to show currently playing tracks, Spotify needs to be actually running! Start playing something in Spotify (you can minimize the app afterwards) and Lofi should work as expected.

So it's a visualizer, not a player. Can it work without having the Spotify app running?

I'm currently using librespot on my headless rpi acting as a spotify-enabled speaker but sometimes it has sync errors, so I'm in the market for alternative tiny players.

What's a sync error in this context ?

Devices/apps not being able to see each other or hand off playback reliably (mostly works but sometimes I meed to restart the rpi client).

As opposed to playback, once it's playing, it's smooth, no complaint there.

As a Linux user, I've given up on alternative Spotify clients. The official client sucks... but at least it works consistently and has full feature support.

Instead of replacing it, I've resolved to minimize my interaction with the client as much as possible via rofi[1] and media shortcuts.

[1]: https://github.com/davidborzek/spofi

What about the web client?

Psst: Fast Spotify client with native GUI, without Electron, built in Rust

https://github.com/jpochyla/psst

20210816 https://news.ycombinator.com/item?id=28203654

Psst seems to be missing a lot of basic functionality at this point. E.g. you can't reorder albums, they are presented in the order they were added to your library. It's promising but I can't see myself using it day-to-day in its current state.

I wish there was a mature, non-Electron Spotify client that worked in Linux. I just use the web because the official Linux client is so flaky.

https://news.ycombinator.com/item?id=28203654#28207594

> https://github.com/hrkfdn/ncspot https://github.com/Rigellute/spotify-tui https://github.com/xou816/spot

https://news.ycombinator.com/item?id=28203654&p=2#28206619

> macOs … https://github.com/toothbrush/Spotiqueue

Spotify-tui is the only one that implements connect functionality, and even then it doesn't have the extended auto-mixes that spotify plays when you're playlist ends.

I'm glad there are options for alternative native clients, but none of them are anywhere near feature parity with the official client

> Very early in development, lacking in features, stability, and general user experience.

I wish there was more movement in the native GUI space, at the moment it feels like everything (even official clients from companies that have the funds to have native developers for every platform) are built in a web technology.

It feels like you get the OS's native toolkit - which is fine, it just means you can't easily have one design across multiple operating systems - and tools like QT which go back decades. I know there's some GUI toolkits for new languages like Go and Rust, but they're often very barebones and since there's no commercial interest in them, they don't develop into full-scale native UI libraries.

I mean as a compromise, is React Native a thing for desktop applications yet?

Totally unrelated: why is the "bug" emoji a caterpillar (https://emojipedia.org/bug/)? Ok, you could say all insects (including preliminary stages) can be called bugs, but if you did a poll, probably most would imagine a bug as a beetle or a "true bug" (https://en.wikipedia.org/wiki/Hemiptera)...

+1. There's even "beetle" [0.a], "cockroach" [0.b] and "fly" [0.c] emoji in the Unicode, that are way closer to what I envision as a "software bug" than caterpillars, centipedes (!)[2.c] and even slugs (!!)[1.a] that are used to represent the "bug" you've linked [1].

And yes, technically it should be a moth [2], probably (?).

[0.a] https://emojipedia.org/beetle/ [0.b] https://emojipedia.org/cockroach/ [0.c] https://emojipedia.org/fly/ [1] https://emojipedia.org/bug/ [1.a] https://emojipedia.org/mozilla/firefox-os-2.5/bug/ [2] https://education.nationalgeographic.org/resource/worlds-fir...

I usually check http://scrumoji.org for some inspiration, there the caterpillar is used for bug so might be the source for some others too!

At a previous job we used https://gitmoji.dev, which scrumoji is based on. At some point I started using the ladybug emoji for bugs because it's actually a bug while my colleagues kept using the caterpillar emoji because they preferred caterpillars. I thought it was a nice way to bring some individuality into our commit messages!

"An inordinate fondness for beetles."

A possibly apocryphal reply to theologians who inquired if there was anything that could be concluded about the Creator from the study of creation; as described in "Homage to Santa Rosalia, or why are there so many kinds of animals" by G. Evelyn Hutchinson in American Naturalist (May-June 1959); This alludes to the fact that there are more types of beetles than any other form of insect, and more insects than any other kind of animal.

https://en.wikiquote.org/wiki/J._B._S._Haldane

the bug is probably a caterpillar, because it is way cuter and easier to distinguish. ...or they might have just looked at https://gitmoji.dev/

This is really cool !

I built a self hosted Spotify alternative a while back. The idea was to be able to listed to your own music from anywhere with most of the useful features of Spotify.

https://github.com/yzdbg/dstream

Python 2 is an interesting choice

Maybe because the initial commit was in January 2019:

https://github.com/dvx/lofi/commit/caf81d949d4c7d5177507139f...

It was an interesting choice even in 2019. Python 2 was sunset on January 1, 2020.

Python 3 came out in 2008.

Python 2 was an odd choice 4 years ago.

it appears to be a node application with the python2 dependency inexplicably being needed for some sort of node FFI build tool

I think the Python 2 requirement is just a mistake in the README, I'm pretty sure the node-gyp version they're using only supports python 3.

I was hoping for something tiny in resources, not just window size.

I miss Billy - https://www.sheepfriends.com/index-page=billy.html

I really wish we could see a low-resource-usage development movement akin to the lofi / retro gaming trend (playdate etc) . I have MS Office 2003 installed on my thinkpad and it starts instantly. It's very satisfying. I feel like apps just grow and grow in size and memory usage to match the average spec of machine instead of being truly thrifty

This project is really cool!

It's kinda unfortunate that there is still no real replacement for libspotify on Windows, and that you have to have the desktop application installed and running.

That's why I would rather call this tool a Spotify desktop remote control than a player...

I am using the Spotify integration for home assistant, an IKEA ZigBee remote and a Chromecast for the actual playback.

Works like a charm

Yes, I agree. Doesn’t make it less cool, though.

I would love to see a port of librespot for Windows, but my guess is that Spotify tolerates librespot, because it’s only available for *nix.

Librespot should work under Windows. There's multiple audio backends available, some are platform specific.

> We recently switched to using Rodio for audio playback by default, hence for macOS and Windows, you should just be able to clone and build librespot (with the command below).

The "recently" above was ~4 years ago!

https://github.com/librespot-org/librespot#readme

This is neat!

One note: for loopback on macOS, instead of iShowU Audio Capture Device, one could also use BlackHole, which is open source: https://github.com/ExistentialAudio/BlackHole

And can be installed with brew:

    brew install blackhole-2ch

The Germans need to help us come up with a word for that feeling when you click on a project expecting to use it only to find it's another Electron type application and click back disappointed.

This is like the winamp mini player

I came here to drop the same comment.

However WinAmp had a slightly smaller memory footprint...

WinAmp is currently using... 28MB.

This is an Electron app which requires another Electron app to be running at the same time. What a time to be alive.

28 MB? For two Electron apps? This seems off by at least one decimal place.

No no... Winamp is 28MB.

"This" refers to the Spotify thing at the top of the page, which I have not tried!

28MB? Damn it got bloated.

> To build, you'll need node-gyp, a compatible Python version (2.x)

...

Reply on news.ycombinator.com