fix: volume percentage briefly reverting after user change#192
Open
1knth wants to merge 1 commit intoLargeModGames:mainfrom
Open
fix: volume percentage briefly reverting after user change#1921knth wants to merge 1 commit intoLargeModGames:mainfrom
1knth wants to merge 1 commit intoLargeModGames:mainfrom
Conversation
The Spotify API can return stale playback state after a local volume change. When the user presses volume up, the UI updates immediately, but the next API poll might still return the old value — causing the percentage to flash back before correcting. Now we keep `pending_volume` set until the API confirms the new value, so the UI always reflects the user's intent during and after a change. Co-Authored-By: opencode <noreply@opencode.ai>
Author
|
my agent hallucinated initial pr message. sorry! |
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
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
Fixes the volume percentage briefly flashing back to an old value after the user changes it, especially noticeable when spamming volume up/down.
Why
Spotify's API returns playback state on a polling interval. After a local volume change, the next poll response can still carry the old volume. Previously this would overwrite the user's intended value in the UI before the API caught up.
Before
UI read volume directly from the API response — no awareness of user intent:
increase_volume calculated from the (potentially stale) API value:
change_volume just updated context directly — no coalescing or stale-response protection:
VolumeChanged handler blindly overwrote local state on every event:
UI and volume-adjust functions use desired_volume() — always shows user's last input:
change_volume coalesces rapid presses and keeps pending_volume alive until the API confirms:
API poll checks if Spotify caught up — stale responses are ignored:
VolumeChanged handler skips overwrite when user has a pending change, still persists config:
Testing: