Interest in expanding Metadata impls for Track and Album, adding a ContextChanged event mechanism

[capnfabs]

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 (4f54dc8); 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 b28bea3. 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: Spotifyd/spotifyd#977 (comment)).

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

[roderickvd]

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.