starred/librespot

Fork 0

mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 00:05:55 +03:00

[GH-ISSUE #1448] Expose updates from other connect devices when not active #649

New issue

Open

opened 2026-02-27 19:31:46 +03:00 by kerem · 4 comments

kerem commented

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

Owner

Originally created by @photovoltex on GitHub (Jan 18, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1448

Is your feature request related to a problem? Please describe.
When implementing librespot as client (mostly GUI related) and not being the active connect device, there isn't any option to update the client UI as the remote events/updates are not exposed.

Describe the solution you'd like
It would be nice to call a similar method like player_event_handler on the spirc instance to retrieve a channel that exposes remote updates. Additionally we could also provide some local updates that exposes internal knowledge like the current next and previous tracks for example.

Additional context

remote updates are send as ClusterUpdate
- https://github.com/librespot-org/librespot/blob/dev/connect/src/spirc.rs#L816
updates to the remote server when we are active are send as PutStateRequest
- https://github.com/librespot-org/librespot/blob/dev/connect/src/spirc.rs#L1525

Originally created by @photovoltex on GitHub (Jan 18, 2025). Original GitHub issue: https://github.com/librespot-org/librespot/issues/1448 **Is your feature request related to a problem? Please describe.** When implementing `librespot` as client (mostly GUI related) and not being the active connect device, there isn't any option to update the client UI as the remote events/updates are not exposed. **Describe the solution you'd like** It would be nice to call a similar method like `player_event_handler` on the spirc instance to retrieve a channel that exposes remote updates. Additionally we could also provide some local updates that exposes internal knowledge like the current next and previous tracks for example. **Additional context** - remote updates are send as `ClusterUpdate` - https://github.com/librespot-org/librespot/blob/dev/connect/src/spirc.rs#L816 - updates to the remote server when we are active are send as `PutStateRequest` - https://github.com/librespot-org/librespot/blob/dev/connect/src/spirc.rs#L1525

kerem added the

enhancement

label

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

kerem commented

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

Author

Owner

@hrkfdn commented on GitHub (Sep 1, 2025):

This is nice. There's already a bunch of useful events to keep track of the player, but one challenge I'm seeing is how to keep track of the playback context, i.e. expose changes to the current playlist or queue.

It could also be useful to offer APIs for context manipulation, for instance when the user removes a track from the queue (that is not a playlist). Though I'm not sure if that's even feasible.

@hrkfdn commented on GitHub (Sep 1, 2025): This is nice. There's already a bunch of useful events to keep track of the player, but one challenge I'm seeing is how to keep track of the playback context, i.e. expose changes to the current playlist or queue. It could also be useful to offer APIs for context manipulation, for instance when the user removes a track from the queue (that is not a playlist). Though I'm not sure if that's even feasible.

kerem commented

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

Author

Owner

@photovoltex commented on GitHub (Sep 1, 2025):

Yeah that should also be be doable. As we are the active device we don't need to go over any apis we can just modify the next tracks which are just a mix of context, queue and autoplay items depending on the current state. After "publishing" the state again, the passive connect devices update their state to the active state. Anyhow...

but one challenge I'm seeing is how to keep track of the playback context, i.e. expose changes to the current playlist or queue.

Yes that's the biggest part we have to get right. I see two options currently:

either we just expose it "as is" (lazy and more flexible option)
- we could forward only some parts like prev_tracks and next_tracks
- or forward the entire state
or we expose it preprocessed (library handling with less flexibility, but easier usage)
- that means holding additional data and only providing specific events/data to the user
- this could be like "track added", "context changed", "track removed", etc.

@photovoltex commented on GitHub (Sep 1, 2025): Yeah that should also be be doable. As we are the active device we don't need to go over any apis we can just modify the next tracks which are just a mix of context, queue and autoplay items depending on the current state. After "publishing" the state again, the passive connect devices update their state to the active state. Anyhow... > but one challenge I'm seeing is how to keep track of the playback context, i.e. expose changes to the current playlist or queue. Yes that's the biggest part we have to get right. I see two options currently: - either we just expose it "as is" (lazy and more flexible option) - we could forward only some parts like `prev_tracks` and `next_tracks` - or forward the entire state - or we expose it preprocessed (library handling with less flexibility, but easier usage) - that means holding additional data and only providing specific events/data to the user - this could be like "track added", "context changed", "track removed", etc.

kerem commented

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

Author

Owner

@hrkfdn commented on GitHub (Sep 1, 2025):

I can only speak for myself/ncspot, of course. So some of this may not necessarily make sense from a library perspective, buuuut:

Maybe the first option is good as an MVP approach? I think just forwarding the entire state/sending events on changes could already be a win and maybe flexible is actually good, not sure if all of the ncspot behavior even translates to Spotify Connect clients 😅

@hrkfdn commented on GitHub (Sep 1, 2025): I can only speak for myself/ncspot, of course. So some of this may not necessarily make sense from a library perspective, buuuut: Maybe the first option is good as an MVP approach? I think just forwarding the entire state/sending events on changes could already be a win and maybe flexible is actually good, not sure if all of the ncspot behavior even translates to Spotify Connect clients 😅

kerem commented

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

Author

Owner

@photovoltex commented on GitHub (Sep 9, 2025):

I made a quick initial implementation (https://github.com/photovoltex/librespot/tree/feat/forward-player-state) where it just forwards the underlying PlayerState. This is pretty ruff so I will probably look into how we can make it easier to work with.

@photovoltex commented on GitHub (Sep 9, 2025): I made a quick initial implementation (https://github.com/photovoltex/librespot/tree/feat/forward-player-state) where it just forwards the underlying `PlayerState`. This is pretty ruff so I will probably look into how we can make it easier to work with.

kerem referenced this issue

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

[PR #649] [MERGED] [Tokio migration] Merge dev and refactor #999

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

No description provided.

Rows
Columns