Draft: Add MPRIS support

[wisp3rwind]

I've been playing around with adding MPRIS support to librespot, i.e. have it implement the org.mpris.MediaPlayer2 interface on DBus. Other software (such as the CLI tool playerctl, or a service managing a smart speaker, as for example in HifiBerryOS or similar projects) can use this to obtain playback status, metadata and to control the player.

This is achieved by hooking into the existing PlayerEvents and sending spirc commands.

Currently, this is a working implementation (at least I've tested manually using playerctl), but a few things are missing (at least doc + changelog updates, run cargo fmt + cargo clippy, only compile this on systems which support DBus, check implementation again against the MPRIS specification).

Thus, I'm not really asking for detailed feedback yet, but I'd be curious to know:

• Would you generally consider this in scope for the project, i.e. could this be merged upstream?
• Should this be enabled by default? (There's a new dependency on zbus required for the feature.) Should it be configurable whether the MPRIS service runs from the command line?
• Any concerns regarding the new spirc command that I added?

The PR adds quite a lot of code, but this is almost exclusively contained in the new MPRIS task. Changes to existing components are quite minimal.

Thanks!

[roderickvd]

Thanks for proposing it!

For completeness sake, I believe ncspot also has MPRIS support: https://github.com/hrkfdn/ncspot

Let's entertain some open discussion on why or why not this could belong to librespot, before I bias the discussion with my own thoughts (which are not set in stone either).

[wisp3rwind]

For completeness sake, I believe ncspot also has MPRIS support: https://github.com/hrkfdn/ncspot

Thanks for the pointer, I wasn't aware of ncspot before!

Let's entertain some open discussion on why or why not this could belong to librespot, before I bias the discussion with my own thoughts (which are not set in stone either).

Sounds good!

[JockeTF]

I'm interested in this! I've been migrating from spotifyd since librespot does most of what I need on its own. The lack of MPRIS is a bit of a downer since that does a lot of heavy lifting for integration with everything. Remote controls and media buttons just work whenever something implements MPRIS.

[roderickvd]

I'm thinking it'd be good if we could feature-gate this. So the additional dependencies are optional for anyone not needing MPRIS.

[wisp3rwind]

I'm thinking it'd be good if we could feature-gate this. So the additional dependencies are optional for anyone not needing MPRIS.

There already is, see the with-mpris Cargo feature.

In any case; I think this needs more work before it should be merged. I'll change the PR state from Draft to ready once I think it makes sense to review it properly.

[roderickvd]

Perfect! Missed that.

[gartnera]

I was testing this out today, but playerctl play-pause wasn't working. I implemented it quickly and this seems to be working well now (at least for my setup).

[Copilot]

Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.

[paulfariello]

For anyone who finds this PR useful, I've rebased it on the latest dev branch. You can find it here: https://github.com/paulfariello/librespot/tree/mpris.

Has any decision been made regarding the integration? (cf #1341 (comment))

For what it's worth, I use librespot as a service on my laptop and don't need a full-featured client, just a simple way to play/pause via MPRIS.

I also guess that clients could easily drop their MPRIS implementation if librespot were to provide it.

[roderickvd]

For anyone who finds this PR useful, I've rebased it on the latest dev branch. You can find it here: https://github.com/paulfariello/librespot/tree/mpris.

That's great, thanks so much for posting it here!

Has any decision been made regarding the integration? (cf #1341 (comment))

I'd be in favor. I was under the impression that the original author wanted to do more work on it first. What do you think?

[wisp3rwind]

Sorry for the long silence here! I've definitely put this on the back burner; I think it's unlikely that I'll wrap it up soon.

@paulfariello I've seen that you've also added a few small improvements to your branch already: If you'd be interested in moving this forward starting from my code in a new PR, please go ahead!

I'm not quite sure anymore what I still wanted to do here. Here's a few things I'm thinking of right now when scrolling through the code again:

• Verify that implemented commands really follow the MPRIS spec (i.e. they take exactly the intended action).

• Check error handling: Are there any unwraps/expects left over that should be handled more gracefully? (There are some, but they might be fine.)

• This PR contains pieces of documentation copied from the MPRIS spec which I pasted here to have them easily reference-able while developing. However, I'm not sure whether there are any license concerns with that, and it's also overly verbose as documentation here. We should probably remove those, and simply ensure that there's a link to the spec so it's easy enough to jump there.

• Check unimplemented commands: Are there still some missing that one would consider essential for an initial implementation, or can they be added later as required?

• Check FIXME and TODO comments: Is there anything that really needs to be addressed before merging?

[paulfariello]

Thanks @wisp3rwind.

I've opened a new PR #1596, will try to fix as much TODOs as possible.