Alternative way to control playback on spotifyd

[joshas]

I've set up spotifyd on RaspberryPi and it works great as Spotify Connect device. Now I want to add playback controls directly on RaspberryPi, like physical buttons. Is there an alternative way to control spotifyd: play/pause music, skip to next track, or event start playing another track by giving Spotify URI? I know about DBUS MPRIS, but dbus-send doesn't want to work on Raspbian Lite as it runs without X11 server. Also provided "slim" build of spotifyd ARMv6 probably doesn't include dbus_mpris feature.

[Yarn]

Currently I don't think so.

Related: https://github.com/librespot-org/librespot/pull/376

I think it would be useful to implement this in spotifyd (and agree it doesn't belong in librespot). It would probably be nice to add http endpoints so something simple like a play/pause button doesn't need to worry about having a websocket client.

I can work on this at some point soon probably.

[mainrs]

Should I assign you to the issue @Yarn?

[Yarn]

Should I assign you to the issue @Yarn?

Sure

[mainrs]

I am not against this feature. The only real downside I could think of is the fact that this introduces another layer of code that needs to be maintained.

I would like to discuss this feature once you want to start and implement this. Mainly about how to design the web API. It should, nevertheless, definitely be behind a feature flag.

The simplest thing to do would be to map properties and methods in a similar fashion to http://localhost:3030/propertyname or http://localhost:3030/methodname.

I'm open for other suggestions. The scheme is probably easy to change anyway afterwards as it's just different hard-coded strings.

[Yarn]

The scheme is probably easy to change anyway afterwards

The issue is more breaking compatibility with anything people have already built around it. I think just saying it's unstable at the start is fine though.

[bluepuma77]

Sounds like a great idea, using the D-Bus interface isn't my first choice either :-)

I am currently building a music box for my kids, based on a headless Raspberry Pi Zero. I have been researching a while about Spotify players, connect players and controls. My current status is that I need something like spotifyd based on librespot and a different tool like spotipy or pyfy (both with different auth mechanisms) to access the Spotify Web API to control it.

I thought about it and here are 3 options I can see:

1. Re-use the current D-Bus control commands with a different interface technology, e.g. http or Socket.io. For me that enables easier developer access to the existing commands. For me the question is if you can provide nice control options like getting current position (album/title/sec) and resuming at position (album/title/sec) - this is what I like to use, besides regular prev/next and search & play title/album.
2. The Spotify web API offers a lot of functionality, maybe it makes sense to just provide a http interface and pass back and forth pure REST JSON calls, just adding the necessary authentication. This would enable the latest features and you don't have to adapt all the time, it even enables latest beta functionality, like fetching current position in an album and also resuming within an album at the same point later on.
3. If you don't want to be an auth-adding proxy, maybe just provide the current auth credentials to developers. Something like 'spotifyd -viewauth' could just output the current token and the developer can use it to interface with the Spotify Web API directly. Kind of a quick&dirty hack, too bad I don't know Rust ;-)

Just my two cents.

[bluepuma77]

I found a librespot example that starts playing a Spotify title. It would be great if that could be exposed somehow. Play title, album, playlist. Trigger start, stop, pause, toggle, next, previous.

Maybe it doesn't even need a http or socket interface but the spotifyd CLI can just "talk" to the local spotifyd backend. As an example mocp --server starts the local backend and you can control it with mocp --append <folder-with-MP3s> --play.

[Yarn]

I've managed to bootstrap together an initial prototype. It can play/pause when it receives an HTTP request.

I'm currently leaning toward splitting this functionality into a different crate just to keep different versions of things separate (especially with cargo doc where it just overwrites all but one version of a crate). I don't think I'll have much luck actually getting a web server working within the current async code so I'm going with a separate executor communicating with a channel then waking the event loop.

[intika]

here is an alternative to control spotifyd without dbus https://github.com/jingweno/spotctl

[PaulFinch]

Actually i managed to use MPRIS dbus to control the player. I created a dedicated bus with systemd, and pointed each daemon (spotifyd and my control script) to the dedicated session dbus. Would work with playerctl as well by exposing the dbus address. I can post more details if needed. The only thing is i needed to compile spotifyd on rpi0 as the binary armv6/full was not available. Took 5 hours ... Anybody know why the armv6 full is not available ?

[intika]

Anybody know why the armv6 full is not available ?

because it takes 5h to build lol :p

[PaulFinch]

Indeed, but it should be a good reason to provide it, to avoid people losing 5 hours ^^

[PaulFinch]

More details here

[intika]

very nice home made setup, i love it.

I just finished an application to control spotify/spotifyd in python... can be helpful for spotifyd's users

https://github.com/Intika-Linux-Spotify/Spotimaster

[PaulFinch]

What a good proper work.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Yarn]

bad bot, i'm just extremely slow

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[schickling]

Still interested in this. Please re-open.