starred/librespot

Fork 0

mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 08:15:50 +03:00

[GH-ISSUE #828] Interest in expanding Metadata impls for Track and Album, adding a ContextChanged event mechanism #420

New issue

Closed

opened 2026-02-27 19:30:30 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 19:30:30 +03:00

Owner

Originally created by @capnfabs on GitHub (Aug 2, 2021).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/828

Hi team,

I'm making some changes to spotifyd so that it can obtain enough information for its MPRIS implementation from librespot. I'm interested in making some changes to librespot to support this, and wanted to check if that seemed reasonable before opening PRs :)

The main thing I'd like for this is to expand the metadata::Track and metadata::Album structs so that they have a more complete set of info. It seems like this information is available in the proto that's used to create these structs, but that it's not plumbed through yet. The change seems simple (github.com/librespot-org/librespot@4f54dc8f5b); would it be ok to submit a PR for this?

Another thing I'd like a way of knowing when the context changes (both context URI, and track number from playlist). I put together a way of doing that using a mechanism similar to PlayerEvents in github.com/librespot-org/librespot@b28bea31ff. Does this seem more broadly useful, and would a PR for this be worthwhile? Is there a better way to do it?

Finally, is there a way of retrieving Loop/Shuffle status from librespot? I'm interested because spotifyd's MPRIS implementation pulls this from the Spotify API (using rspotify), which interacts badly with playerctl, resulting in delays when running playerctl play-pause targeting spotifyd (details here: https://github.com/Spotifyd/spotifyd/pull/977#issuecomment-890578852).

Thanks in advance, and thanks also for all your work on librespot!

Originally created by @capnfabs on GitHub (Aug 2, 2021). Original GitHub issue: https://github.com/librespot-org/librespot/issues/828 Hi team, I'm making some changes to [`spotifyd`](https://github.com/Spotifyd/spotifyd) so that it can obtain enough information for its [MPRIS](https://specifications.freedesktop.org/mpris-spec/latest/) implementation from librespot. I'm interested in making some changes to librespot to support this, and wanted to check if that seemed reasonable before opening PRs :) The main thing I'd like for this is to expand the `metadata::Track` and `metadata::Album` structs so that they have a more complete set of info. It seems like this information is available in the proto that's used to create these structs, but that it's not plumbed through yet. The change seems simple (https://github.com/librespot-org/librespot/commit/4f54dc8f5b5b9191899b9159801958cc3e748de9); would it be ok to submit a PR for this? Another thing I'd like a way of knowing when the context changes (both context URI, and track number from playlist). I put together a way of doing that using a mechanism similar to PlayerEvents in https://github.com/librespot-org/librespot/commit/b28bea31ff7eefb5ef1e8d8a897c741a891098fc. Does this seem more broadly useful, and would a PR for this be worthwhile? Is there a better way to do it? Finally, is there a way of retrieving Loop/Shuffle status from librespot? I'm interested because `spotifyd`'s MPRIS implementation pulls this from the Spotify API (using `rspotify`), which interacts badly with `playerctl`, resulting in delays when running `playerctl play-pause` targeting spotifyd (details here: https://github.com/Spotifyd/spotifyd/pull/977#issuecomment-890578852). Thanks in advance, and thanks also for all your work on librespot!

kerem

2026-02-27 19:30:30 +03:00

closed this issue
added the
enhancement

reverse engineering
labels

kerem commented

2026-02-27 19:30:31 +03:00

Author

Owner

@roderickvd commented on GitHub (Aug 7, 2021):

I'm making some changes to spotifyd so that it can obtain enough information for its MPRIS implementation from librespot. I'm interested in making some changes to librespot to support this, and wanted to check if that seemed reasonable before opening PRs :)

Thanks for chiming in.

The main thing I'd like for this is to expand the metadata::Track and metadata::Album structs so that they have a more complete set of info. It seems like this information is available in the proto that's used to create these structs, but that it's not plumbed through yet. The change seems simple (4f54dc8); would it be ok to submit a PR for this?

Yeah, let's get that in a PR.

Another thing I'd like a way of knowing when the context changes (both context URI, and track number from playlist). I put together a way of doing that using a mechanism similar to PlayerEvents in b28bea3. Does this seem more broadly useful, and would a PR for this be worthwhile? Is there a better way to do it?

Ideally it would all be dispatched under the same --onevent handler.

Finally, is there a way of retrieving Loop/Shuffle status from librespot? I'm interested because spotifyd's MPRIS implementation pulls this from the Spotify API (using rspotify), which interacts badly with playerctl, resulting in delays when running playerctl play-pause targeting spotifyd (details here: Spotifyd/spotifyd#977 (comment)).

I've been asking this question myself as I've been working on new-api. From the proto's, I don't think so? To double-check, you could best read through the librespot-java code. If it's there, @devgianlu will have implemented it.

@roderickvd commented on GitHub (Aug 7, 2021): > I'm making some changes to [`spotifyd`](https://github.com/Spotifyd/spotifyd) so that it can obtain enough information for its [MPRIS](https://specifications.freedesktop.org/mpris-spec/latest/) implementation from librespot. I'm interested in making some changes to librespot to support this, and wanted to check if that seemed reasonable before opening PRs :) Thanks for chiming in. > The main thing I'd like for this is to expand the `metadata::Track` and `metadata::Album` structs so that they have a more complete set of info. It seems like this information is available in the proto that's used to create these structs, but that it's not plumbed through yet. The change seems simple ([4f54dc8](https://github.com/librespot-org/librespot/commit/4f54dc8f5b5b9191899b9159801958cc3e748de9)); would it be ok to submit a PR for this? Yeah, let's get that in a PR. > Another thing I'd like a way of knowing when the context changes (both context URI, and track number from playlist). I put together a way of doing that using a mechanism similar to PlayerEvents in [b28bea3](https://github.com/librespot-org/librespot/commit/b28bea31ff7eefb5ef1e8d8a897c741a891098fc). Does this seem more broadly useful, and would a PR for this be worthwhile? Is there a better way to do it? Ideally it would all be dispatched under the same `--onevent` handler. > Finally, is there a way of retrieving Loop/Shuffle status from librespot? I'm interested because `spotifyd`'s MPRIS implementation pulls this from the Spotify API (using `rspotify`), which interacts badly with `playerctl`, resulting in delays when running `playerctl play-pause` targeting spotifyd (details here: [Spotifyd/spotifyd#977 (comment)](https://github.com/Spotifyd/spotifyd/pull/977#issuecomment-890578852)). I've been asking this question myself as I've been working on `new-api`. From the proto's, I don't think so? To double-check, you could best read through the `librespot-java` code. If it's there, @devgianlu will have implemented it.

kerem referenced this issue

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

[PR #421] [MERGED] Don't panic when no autoplay uri is obtained #915

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#420

No description provided.

Rows
Columns