[PR #1341] [CLOSED] Draft: Add MPRIS support #1345

New issue

Closed

opened 2026-02-27 20:02:05 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 20:02:05 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/librespot-org/librespot/pull/1341
Author: @wisp3rwind
Created: 9/18/2024
Status: ❌ Closed

Base: dev ← Head: add-mpris

📝 Commits (4)

949a886 Allow cloning SPIRC
055e0d8 add release date to AudioItem
8093981 add Spirc.seek_offset command
de5a296 add initial MPRIS support using zbus

📊 Changes

7 files changed (+1263 additions, -1 deletions)

View changed files

📝 Cargo.lock (+3 -0)
📝 Cargo.toml (+6 -1)
📝 connect/src/spirc.rs (+28 -0)
📝 metadata/src/audio/item.rs (+4 -0)
📝 src/main.rs (+20 -0)
➕ src/mpris_event_handler.rs (+1197 -0)
📝 src/player_event_handler.rs (+5 -0)

📄 Description

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!

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/librespot-org/librespot/pull/1341 **Author:** [@wisp3rwind](https://github.com/wisp3rwind) **Created:** 9/18/2024 **Status:** ❌ Closed **Base:** `dev` ← **Head:** `add-mpris` --- ### 📝 Commits (4) - [`949a886`](https://github.com/librespot-org/librespot/commit/949a886f6215c79c2a0f92dfb91d6dc635e31d31) Allow cloning SPIRC - [`055e0d8`](https://github.com/librespot-org/librespot/commit/055e0d8f381916ee44eca6f38c0d2e29d6ea9ece) add release date to AudioItem - [`8093981`](https://github.com/librespot-org/librespot/commit/80939819ddbca9923feb8e9bb832735575d789ab) add Spirc.seek_offset command - [`de5a296`](https://github.com/librespot-org/librespot/commit/de5a2969b7fc84dbc8202a46d371514012403777) add initial MPRIS support using zbus ### 📊 Changes **7 files changed** (+1263 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `Cargo.lock` (+3 -0) 📝 `Cargo.toml` (+6 -1) 📝 `connect/src/spirc.rs` (+28 -0) 📝 `metadata/src/audio/item.rs` (+4 -0) 📝 `src/main.rs` (+20 -0) ➕ `src/mpris_event_handler.rs` (+1197 -0) 📝 `src/player_event_handler.rs` (+5 -0) </details> ### 📄 Description I've been playing around with adding MPRIS support to librespot, i.e. have it implement the [`org.mpris.MediaPlayer2`](https://specifications.freedesktop.org/mpris-spec/latest/) 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 `PlayerEvent`s 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! --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem

2026-02-27 20:02:05 +03:00

closed this issue
added the
pull-request
label

kerem referenced this issue

2026-02-27 20:02:06 +03:00

[PR #1345] [MERGED] core: retry session connection #1348

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#1345

No description provided.

Rows
Columns