This actually implements the reverse-engineered Spotify protocol and authenticates as a Spotify Connect device. To avoid Spotify being mad and potential legal problems, they implemented artificial limitations that block you from extracting the audio files unencrypted or using premium features on free accounts. A skilled Rustecean could probably deal with those pretty quickly, though.
By the way with puppeteer you can login and intercept the bearer auth token to masquerade as the web player.
1: https://6xq.net/pianobar/ or https://github.com/PromyLOPh/pianobar
Also a shoutout to xmms2: https://en.wikipedia.org/wiki/XMMS2
I'll try this out later.
`spotify-tui` uses the Spotify Web API, which doesn't handle streaming itself, so as of now you'll need a spotify client that handles streaming.
In the future, I'll see if I can integrate this into the project for a more complete package.
My main issue with the snap install (debian) browsing for songs became slow initially. The UI will be there but it'll just show 'no results' for basically any search until after a minute or so.
A minimal Spotify controller for the menubar/systray. I mostly play on speakers, though sometimes librespot on my desktop to avoid running the hog of the Spotify app. The main feature for me, though, is the alarm clock; I set a raspberry pi to push a new release playlist to one of my speakers every morning.
Will it ever be possible to have it work without the app open?
+1 on Spotify memory/CPU bloat
We also integrated Spotify into Pragli to show “show your status”. If I can see that you’re listening to Spotify, you could be heads down but you’re definitely not on a call. Also could be useful as a social signal if you decide to decide to add a social component to your app
It would be cool to see separate commands for simple operations like stop, play, and skip without having to even open the tui
More seriously, though: the heaviest of my Emacs processes right now is at around 28k of resident memory, while Rambox (Electron wrapper around Gmail and GCal, among potentially other things) is at 395MB + 195MB (presumably for the Gmail and GCal tabs) + some other more negligible subprocesses, and Slack is at 265MB. Total virtual/mapped memory is much higher for all of those (Emacs is still the lowest, at 541MB for the biggest process, while Rambox's are around 1GB each and Slack's is at a "mere" 20.8GB).
Granted, my Emacs processes are doing a bit less than any of the Electron processes, but I still think you've got things the wrong way round :)