expose remote state by ralphptorres · Pull Request #1704 · librespot-org/librespot

ralphptorres · 2026-04-18T10:39:48Z

expose 3 broadcast/watch channel pairs to observe remote playback and other states. pattern-wise, broadcast channels (lightweight) emit only update (or state change) events with semantic reasons. watch channels (stateful) emit complete state snapshots

cluster
- broadcast when device list (dis/appeared, active device) or info (volume, alias) changes
- watch current ClusterState with all device info and active device id
- use case: mpris lifecycle, device picker ui
player
- broadcast when track, play/pause, position, shuffle, repeat or context changes
- watch current PlayerState snapshot
- use: remote playback ui, track changes, pause/resume
queue
- broadcast when when prev or next track queue changes
- watch current QueueList snapshot
- use: queue ui refresh, skip detection, upcoming track preview

partially closes #1448

also fixed

ShuffleChanged/RepeatChanged/SetQueue player events never carried a play_request_id so the pre-existing gate in handle_player_event silently dropped them before update_state was set. this pr narrows the gate to only the events that actually carry one

semantically diff for player changes. also emit cluster and queue updates to their broadcast channels

use server cluster update reasons for cluster changes. also emit cluster topology snapshots with all devices and active device

diff prev and next tracks for queue changes. also emit queue list

Copilot

Pull request overview

This PR exposes remote Spotify Connect state updates from Spirc via three broadcast/watch channel pairs (cluster, player, queue) so clients can observe playback/device changes even when this device isn’t the active Connect device (relates to #1448).

Changes:

Added new public state/event types (ClusterState, QueueList, *UpdateEvent, *UpdateReason, DeviceInfo) and associated tokio broadcast/watch channels to Spirc.
Implemented emission of player/cluster/queue update events and state snapshots primarily from incoming ClusterUpdates.
Extended handle_cluster_update to maintain and publish cluster/player/queue state, with diff-based semantic “reason” classification.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-18T10:44:43Z

+                    let info = DeviceInfo {
+                        device_id: device.device_id.clone(),
+                        device_alias: device.name.clone(),
+                        device_type: format!("{:?}", device.device_type),


DeviceInfo.device_type is documented as a human-readable value (e.g. "Speaker", "Phone"), but it’s currently built via format!("{:?}", device.device_type). Since this field is a protobuf enum wrapper, the Debug output is typically not user-friendly/stable. Consider using the enum’s string name (e.g. enum_value_or_default().as_str_name()) or mapping to your own display strings to match the docs.

Suggested change

device_type: format!("{:?}", device.device_type),

device_type: device

.device_type

.enum_value_or_default()

.as_str_name()

.to_string(),

didn't implement -- doesn't work with the protobuf version. could add a proper mapping later if needed

account for elapsed time and play/pause state. also rename to SeekChanged

photovoltex · 2026-07-12T10:36:22Z

Hey, what's the state of this PR @ralphptorres? Ready to merge besides the clippy/fmt fixes?

ralphptorres · 2026-07-13T09:02:01Z

ready now @photovoltex - fmt/clippy clean, plus fixed a few real bugs found along the way (local playback wasn't reaching the broadcast channels, initial connect never hydrated watch state when another device was already active) and added unit tests plus an example. tested end-to-end against spotifyd :)

Broadcast and watch channels for the cluster (devices, active device), the player state and the queue, from librespot-org#1704 by Ralph Torres, squashed onto this fork as of its head dff9e8d. Differences from the pull request: the queue channel does not react to the SetQueue player event, which needs librespot-org#1677 and isn't in this fork, so PlayerUpdateReason::QueueChanged is never sent, and the tests import ProvidedTrack themselves. The changelog keeps only this feature's line.

Broadcast and watch channels for the cluster (devices, active device), the player state and the queue, from librespot-org#1704 by Ralph Torres, squashed as of its head dff9e8d. Only the textual merge with this fork's disconnected-playback code differs from the pull request.

librespot-org#1704 reacts to the SetQueue player event from librespot-org#1677, which this fork doesn't have: drop those two match arms, so PlayerUpdateReason::QueueChanged is never sent. The tests import ProvidedTrack themselves, and the changelog keeps only the line for this feature (the others came from upstream's changelog).

Spotifast learned what another device was doing by polling the Web API every 4 seconds, so a pause or stop there took up to that long, plus a request, to show, and a phone playing for an hour cost about 900 requests. librespot already receives every change on the active device from Spotify the moment it happens. The engine now hands those updates to the app. A pause, seek, shuffle or repeat change on the same song shows at once without a request, a new song or device is looked up at once (and again, up to three times, while the Web API still reports the old one), and the Web API is polled every 30 seconds as a fallback. A device switch that went wrong settles on the first update instead of the next poll. Measured with a second librespot device paused from the web player: Spotifast showed the pause 11 ms after Spotify's update reached the engine. In a minute of playback on the other device it made 2 requests instead of 15. Needs the remote state channels from librespot-org/librespot#1704 on top of Spirc::transfer_to (Magniquick/librespot, branch transfer-to-remote-state).

Spotifast learned what another device was doing by polling the Web API every 4 seconds, so a pause or stop there took up to that long, plus a request, to show, and a phone playing for an hour cost about 900 requests. librespot already receives every change on the active device from Spotify the moment it happens. The engine now hands those updates to the app. A pause, seek, shuffle or repeat change on the same song shows at once without a request, a new song or device is looked up at once (and again, up to three times, while the Web API still reports the old one), and the Web API is polled every 30 seconds as a fallback. A device switch that went wrong settles on the first update instead of the next poll. Measured with a second librespot device paused from the web player: Spotifast showed the pause 11 ms after Spotify's update reached the engine. In a minute of playback on the other device it made 2 requests instead of 15. Needs the remote state channels from librespot-org/librespot#1704 with Spirc::transfer_to on top (Magniquick/librespot, branch remote-state-transfer-to).

photovoltex and others added 8 commits April 14, 2026 10:59

feat: add forwarding channel of the remote and our PlayerState

9170a1b

add broadcast/watch channel types for updates/state

ea633fc

add broadcast/watch channel fields and public api

fb0203b

emit player updates to its broadcast channel

1f4f68e

semantically diff for player changes. also emit cluster and queue updates to their broadcast channels

emit cluster updates/states to its broadcast/watch channels

0f39bdb

use server cluster update reasons for cluster changes. also emit cluster topology snapshots with all devices and active device

emit queue updates/lists to its broadcast/watch channels

5cd8c3e

diff prev and next tracks for queue changes. also emit queue list

remove redundant emit player state call

02e568c

fix vars

d9eaa62

Copilot AI review requested due to automatic review settings April 18, 2026 10:39

Copilot started reviewing on behalf of ralphptorres April 18, 2026 10:40 View session

Copilot AI reviewed Apr 18, 2026

View reviewed changes

ralphptorres added 7 commits April 18, 2026 10:46

fix fmt

7dba9dd

improve seek detection

b0fef94

account for elapsed time and play/pause state. also rename to SeekChanged

emit queue list on first update

e26841a

normalize empty active device id

dab6b2d

emit local player state when device is active

31ea6b2

fix fmt

803b92a

satisfy mr clippy

085c724

ralphptorres added 11 commits July 13, 2026 02:14

broadcast local player/queue updates too

4ef0fe0

trim qualifiers, note reason split

5a61563

extract player-reason classifier, add tests

d383cd9

use real DeviceType enum, add diffing tests

370856f

give SetQueue its own PlayerUpdateReason

4304253

broadcast local volume changes immediately

f1d1204

add example for remote state consumption

e120e68

fix broadcast channel drops and warn spam

4c96f6e

fix device_id sentinel, non_exhaustive enums

6615c18

fix cluster watch/broadcast ordering

bd150d1

split device appeared/disappeared reasons

9e259ad

ralphptorres added 9 commits July 13, 2026 03:24

emit multiple PlayerUpdateEvents per change

d037b96

mirror activation/deactivation into cluster state

2460d84

rename DeviceInfo to avoid protocol collision

877c418

guard local publish on receiver count

c3f76ad

extract cluster reason mapping, add tests

ca0fdbc

guard deactivation against a newer active device

8ab0252

make reason classifier table-driven

9cacb32

hydrate cluster and player state on initial connect

783be74

add changelog entry for remote state channels

dff9e8d

ralphptorres mentioned this pull request Jul 13, 2026

feat: add spectator mode Spotifyd/spotifyd#1407

Draft

woorszt mentioned this pull request Aug 5, 2026

Spotify Connect queue ("Up Next") isn't reflected in LMS/JiveLite/Material Skin stiefenm/spoton#135

Open

This was referenced Sep 27, 2026

A few days of fixes: device switching, remote state, and smaller bugs Magniquick/spotifast#1

Open

A few days of fixes: device switching, remote state, and smaller bugs crmne/spotifast#604

Open

Navigation Menu

expose remote state - #1704

expose remote state#1704
ralphptorres wants to merge 35 commits into
librespot-org:devfrom
ralphptorres:expose-remote-state

ralphptorres commented Apr 18, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI Apr 18, 2026

Uh oh!

ralphptorres Apr 18, 2026

Uh oh!

Uh oh!

photovoltex commented Jul 12, 2026 •

edited

Loading

Uh oh!

ralphptorres commented Jul 13, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

-                        device_type: format!("{:?}", device.device_type),
+                        device_type: device
+                            .device_type
+                            .enum_value_or_default()
+                            .as_str_name()
+                            .to_string(),

Conversation

ralphptorres commented Apr 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI Apr 18, 2026

Choose a reason for hiding this comment

Uh oh!

ralphptorres Apr 18, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

photovoltex commented Jul 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ralphptorres commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ralphptorres commented Apr 18, 2026 •

edited

Loading

photovoltex commented Jul 12, 2026 •

edited

Loading

ralphptorres commented Jul 13, 2026 •

edited

Loading