Conversation
Sonora announces itself as a Spotify Connect playback target when "Play from other devices" is on, so a phone can send music to it. A transfer carries the track in a raw gid rather than ContextTrack::uri, and asks for the position to be extrapolated forward, so both are read before the context is resolved and the queue seated at the right track. Completing a handover needs an active PlayerState published back, or the sending device sits on "Connecting" forever; that state is then republished on every change, throttled, so other devices' UIs follow. Volume arrives on its own endpoint instead of the player command channel, and the announced device carries Sonora's real level so the sliders agree. Handing playback back re-announces Sonora as idle, because going inactive alone takes it out of every picker. The Connect device id is persisted rather than regenerated per session, so a restart no longer leaves a stale Sonora behind.
|
Luxotick#1, which reuses a lot of code from this pr should fully resolve #354, since it adds its own option to always publish playback data even without connecting from a phone/other device. Tested and verified on Linux. |
Luxotick
force-pushed
the
feat/330-spotify-connect-control
branch
from
September 4, 2026 19:23
350a1af to
5a571bf
Compare
|
My mistake, its technically not RPC so strictly speaking it wont actually resolve #354, but effectively your playback will show up on your discord status if you have your Spotify account connected to your Discord account. which was not the case before |
Reworks the hosting-only publish gate so Sonora can optionally report every local play to the Spotify Connect cluster. Behind a new Settings → Playback → Report playback to Spotify toggle (connect_reporting, off by default). - Widens schedule_report / report / obey gates from `self.hosting` to `self.hosting || connect_reporting()`, and the watch now announces itself as playable when either toggle is on. - In broadcast mode report() backs off while idle or when another device is active (reads the cluster to avoid clobbering it), then re-claims the session on the next local play event. - Settings observer restarts the watch on playable-flag transitions and calls stand_down when reporting is turned back off, so the account's device state is cleaned up.
Reacting to every settings notify resigned a live handover. AppSettings notifies its observers on every save, so a volume change, a shuffle toggle or a sidebar drag reached the Connect observer, and with reporting off it stood down. A phone driving Sonora did it to itself: its volume command wrote the level to settings, which notified, which handed playback back. The pair of Connect switches is now read as one value and compared against what the watch was built from, so a notify that moved anything else returns immediately. Standing down needs reporting to have actually been turned off, with no handover to keep; the announcement is only redone when the playable flag itself moves, not when the second switch joins the first. Co-authored-by: oneshinyboi <diamondalonzo@gmail.com>
sonora-buddy
Bot
added
documentation
sonora-buddy
Bot
added
player
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
Adds a spotify device connection with 2 ways one as a host and one as a playback device.
as a controller: player displays all connected active Connect devices on the account and selecting one from the list plays the songs that Sonora plays at the moment, you can control it from the Sonora App.
as a playback target: you must enable it from the Settings menu under "playback" section (play from other devices) this setting sets Sonara as a target when it launches so it can be controlled from other active spotify devices (like your phone, other computer etc.)
How it works?
It bypasses Spirc/librespot-connect to keep Sonora's own engine in control and communicating through librespot_core
added RemoteTransport, RemoteUpdates and HostCommands primitives.
state::Remotes: manages the watching process and mirrors the states of UI and handling playback actions
state::Playback: added adopt_handover (to handle incoming transfers) and hosted (to serialize state for remote devices).
this changes can effect Discord Rich Presence support (#354) but in other way, if user wants the real spotify rich presence in discord when this setting (play from other devices) is on and if you connect from a phone or anywhere because of discord is getting the playback data from spotify and since you're connected to devices it shows a rich presence but not the actual fix for it and doesn't work when you don't connect it from another device
Verified
Tested on windows with Spotify mobile and desktop apps
-Both ways of control transfer and track position works on the platforms
-Remote volume level changes is working.
-Passed all the checks.