[GH-ISSUE #457] [Feature Request] local API for play/pause/skip, etc...

kerem commented

2026-02-27 19:29:50 +03:00

Owner

Originally created by @m-a-x-i-m-z on GitHub (Apr 9, 2020).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/457

I'm using librespot embedded in moodeaudio suite as a headless player based on raspberry-pi zero. In general it's great, but what I'm missing is a possibility to stop/start playback and also skip to the next song in the list (to be activated by the remote control, which is wired and is waiting to be supported by the software).

librespot-java has a local socket-based API, which can be conveniently used from a command line or potentially from a local IR daemon in my case. However, I'm not convinced that running a java thing on the pi-zero hardware is a good idea...

So IDEALLY I would love to know, whether there is a similar API in librespot or whether it can be easily hacked in.

ALTERNATIVELY: I am aware of the official WEB API, however, I'm missing a way of acquiring credentials and IDs of the current spotify user. The player is installed in the living room and is used by five people/accounts, so hard-wiring the login/credentials into the IR event scripts is not an option. But even though it feels strange, that for stopping/pausing the playback locally I have to send a request to a remote server, I would do so if I was aware of getting the bits and pieces needed for forming a spotify's WEB-API request.

Any input is greatly appreciated!

--Max

Originally created by @m-a-x-i-m-z on GitHub (Apr 9, 2020). Original GitHub issue: https://github.com/librespot-org/librespot/issues/457 I'm using librespot embedded in moodeaudio suite as a headless player based on raspberry-pi zero. In general it's great, but what I'm missing is a possibility to stop/start playback and also skip to the next song in the list (to be activated by the remote control, which is wired and is waiting to be supported by the software). librespot-java has a local socket-based API, which can be conveniently used from a command line or potentially from a local IR daemon in my case. However, I'm not convinced that running a java thing on the pi-zero hardware is a good idea... So IDEALLY I would love to know, whether there is a similar API in librespot or whether it can be easily hacked in. ALTERNATIVELY: I am aware of the official WEB API, however, I'm missing a way of acquiring credentials and IDs of the current spotify user. The player is installed in the living room and is used by five people/accounts, so hard-wiring the login/credentials into the IR event scripts is not an option. But even though it feels strange, that for stopping/pausing the playback locally I have to send a request to a remote server, I would do so if I was aware of getting the bits and pieces needed for forming a spotify's WEB-API request. Any input is greatly appreciated! --Max

kerem

2026-02-27 19:29:50 +03:00

closed this issue
added the
enhancement

wontfix
labels

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@bluepuma77 commented on GitHub (Apr 13, 2020):

spotifyd is a "related project" in Rust using librespot, there is a similar feature request.

I have the same challenge, would like to use Spotify Connect and still control music.

Lets see if one of the projects implements this feature 😃

@bluepuma77 commented on GitHub (Apr 13, 2020): [spotifyd](https://github.com/Spotifyd/spotifyd) is a "related project" in Rust using librespot, there is a similar [feature request](https://github.com/Spotifyd/spotifyd/issues/432). I have the same challenge, would like to use Spotify Connect and still control music. Lets see if one of the projects implements this feature 😃

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@ashthespy commented on GitHub (Apr 13, 2020):

I implemented a simple socket over at Vollibrespot that ~~should~~ could someday work its way into librespotd, the fabled daemon version of the librespot library ;-)

@ashthespy commented on GitHub (Apr 13, 2020): I implemented a simple socket over at [`Vollibrespot`](https://github.com/ashthespy/Vollibrespot) that ~should~ could someday work its way into [`librespotd`](https://github.com/librespot-org/librespotd), the fabled daemon version of the `librespot` library ;-)

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@m-a-x-i-m-z commented on GitHub (Apr 15, 2020):

Good pointers, thanks! I'll keep searching... too bad I don't speak Rust... And even if I did it would include setting up a complete cross-compile tool chain for RPI...

@m-a-x-i-m-z commented on GitHub (Apr 15, 2020): Good pointers, thanks! I'll keep <re>searching... too bad I don't speak Rust... And even if I did it would include setting up a complete cross-compile tool chain for RPI...

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@ashthespy commented on GitHub (Apr 15, 2020):

Good pointers, thanks! I'll keep searching... too bad I don't speak Rust... And even if I did it would include setting up a complete cross-compile tool chain for RPI...

FWIW, you could grab a pre-compiled release from https://github.com/ashthespy/Vollibrespot/releases/

The armv6l version should run on all raspbian images..

@ashthespy commented on GitHub (Apr 15, 2020): > Good pointers, thanks! I'll keep <re>searching... too bad I don't speak Rust... And even if I did it would include setting up a complete cross-compile tool chain for RPI... FWIW, you could grab a pre-compiled release from https://github.com/ashthespy/Vollibrespot/releases/ The `armv6l` version should run on all raspbian images..

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@m-a-x-i-m-z commented on GitHub (Apr 16, 2020):

FWIW, you could grab a pre-compiled release from https://github.com/ashthespy/Vollibrespot/releases/tag/v0.1.9

The armv6l version should run on all raspibian images..

OK, it does start, indeed. Great, many thanks! However, now I see two further problems :

the librespot version shipped with moode-player uses option --onevent /var/local/www/commandw/spotevent.sh which does'n seem to be supported by vollibrespot
I've seen some bits and pieces regarding the control socket communication, but not enough to get a picture how it is supposed to work.

I imagine that the simple feedback mechanism of librespot was superseded by the socket mechanism of vollibrespot, so point 1 may be solvable somehow in the end. But for that I need more info about point 2. Any hints?

Thanks in advance!

@m-a-x-i-m-z commented on GitHub (Apr 16, 2020): > FWIW, you could grab a pre-compiled release from https://github.com/ashthespy/Vollibrespot/releases/tag/v0.1.9 > > The `armv6l` version should run on all raspibian images.. OK, it does start, indeed. Great, many thanks! However, now I see two further problems : 1) the librespot version shipped with moode-player uses option --onevent /var/local/www/commandw/spotevent.sh which does'n seem to be supported by vollibrespot 2) I've seen some bits and pieces regarding the control socket communication, but not enough to get a picture how it is supposed to work. I imagine that the simple feedback mechanism of librespot was superseded by the socket mechanism of vollibrespot, so point 1 may be solvable somehow in the end. But for that I need more info about point 2. Any hints? Thanks in advance!

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@ashthespy commented on GitHub (Apr 17, 2020):

@m-a-x-i-m-z vollibrespot was born as a way to pipe metadata to a Volumio plugin, so it caters more to that need, the --onevent was moot as events are instead exposed over a socket and can be used from there. nc -ulp 5030 should give you typical events exposed currently..

It's not meant to be a drop-in replacement for librespot. I was under the impression you wanted to roll your own interface, it should be quiet simple though - ashthespy/Volumio-SpotifyConnect should give you a simple nodejs based implementation.

But this is all a stopgap, and a long term solution would be to have different metadata providers (websocket/REST/socket) etc similar to how we currently have our backends baked into librespotd

@ashthespy commented on GitHub (Apr 17, 2020): @m-a-x-i-m-z `vollibrespot` was born as a way to pipe metadata to a Volumio plugin, so it caters more to that need, the `--onevent` was moot as events are instead exposed over a socket and can be used from there. `nc -ulp 5030` should give you typical events exposed currently.. It's not meant to be a drop-in replacement for librespot. I was under the impression you wanted to roll your own interface, it should be quiet simple though - [ashthespy/Volumio-SpotifyConnect](https://github.com/ashthespy/Volumio-SpotifyConnect/blob/next/SpotConnController.js) should give you a simple nodejs based implementation. **But this is all a stopgap, and a long term solution would be to have different metadata providers (websocket/REST/socket) etc similar to how we currently have our backends baked into `librespotd`**

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@txoof commented on GitHub (May 2, 2020):

@ashthespy
Thanks for the tip on vollibrespot.

I'm trying to pull the "now playing" JSON data from spotify so I can use it for this project:
https://github.com/txoof/slimpi_epd

I've successfully managed to start up vollibrespot; I'd like to connect to it and start pulling the JSON, but I'm not sure where to begin.

Thanks!

@txoof commented on GitHub (May 2, 2020): @ashthespy Thanks for the tip on vollibrespot. I'm trying to pull the "now playing" JSON data from spotify so I can use it for this project: https://github.com/txoof/slimpi_epd I've successfully managed to start up vollibrespot; I'd like to connect to it and start pulling the JSON, but I'm not sure where to begin. Thanks!

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@ashthespy commented on GitHub (May 2, 2020):

@txoof nice project, I have been meaning to do something similar with some nfc cards as well. If you hop onto gitter, I can help you without spamming everyone here ;-)

@ashthespy commented on GitHub (May 2, 2020): @txoof nice project, I have been meaning to do something similar with some nfc cards as well. If you hop onto gitter, I can help you without spamming everyone here ;-)

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@HBeserra commented on GitHub (Jul 23, 2020):

if librespot receives a scope and generates the token, the rest can be done by another application

@HBeserra commented on GitHub (Jul 23, 2020): if librespot receives a scope and generates the token, the rest can be done by another application

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@ashthespy commented on GitHub (Jul 23, 2020):

@HBeserra it does that already - check out keymaster::get_token

@ashthespy commented on GitHub (Jul 23, 2020): @HBeserra it does that already - check out [`keymaster::get_token`](https://docs.rs/librespot-core/0.1.0/librespot_core/keymaster/fn.get_token.html)

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@HBeserra commented on GitHub (Jul 24, 2020):

@ashthespy As I understand it, the get_token () function will generate a token based on a section, scope and client_id, but I would like to receive the most recent token from the connected user.

@HBeserra commented on GitHub (Jul 24, 2020): @ashthespy As I understand it, the get_token () function will generate a token based on a section, scope and client_id, but I would like to receive the most recent token from the connected user.

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@ashthespy commented on GitHub (Jul 24, 2020):

get_token() lets you generate a token (access_token in Spotify's parlance, that with the appropriate scopes can be passed out to an external application that can then control playback, retrieve metadata, or basically what ever Spotify's API's allow you to do..

~~Not sure what you mean by "the most recent token from the connected user" here..~~
Ah - get_token returns a token for the user attached to the current authenticated Session

@ashthespy commented on GitHub (Jul 24, 2020): `get_token()` lets you generate a token (`access_token` in [Spotify's parlance](https://developer.spotify.com/documentation/general/guides/authorization-guide/), that with the appropriate scopes can be passed out to an external application that can then control playback, retrieve metadata, or basically what ever Spotify's API's allow you to do.. ~Not sure what you mean by "the most recent token from the connected user" here..~ Ah - `get_token` returns a token for the user attached to the current authenticated `Session`

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@HBeserra commented on GitHub (Jul 28, 2020):

My goal is to define a scope and export the valid acess_token to another application and update it from time to time.

I didn't find any reference to the function in code besides the keymaster, our a documentation about. Is there any documentation or other repository?

@HBeserra commented on GitHub (Jul 28, 2020): My goal is to define a scope and export the valid `acess_token` to another application and update it from time to time. I didn't find any reference to the function in code besides the keymaster, our a documentation about. Is there any documentation or other repository?

kerem commented

2026-02-27 19:29:51 +03:00

Author

Owner

@ashthespy commented on GitHub (Jul 29, 2020):

@HBeserra Just added #512 as a simple example.

The core library only provides you a way to fetch an API token, and doesn't keep track of the expiry of the token and refresh it. But that is trivial to manage in your end application.. :-)

@ashthespy commented on GitHub (Jul 29, 2020): @HBeserra Just added #512 as a simple example. The core library only provides you a way to fetch an API token, and doesn't keep track of the expiry of the token and refresh it. But that is trivial to manage in your end application.. :-)

Rows
Columns

[GH-ISSUE #457] [Feature Request] local API for play/pause/skip, etc... #290