mirror of
https://github.com/aome510/spotify-player.git
synced 2026-04-26 17:35:50 +03:00
[GH-ISSUE #415] "spotify_player get key playback" sometimes returns outdated information #228
Labels
No labels
bug
documentation
enhancement
good first issue
help wanted
pull-request
question
third-party
third-party
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/spotify-player#228
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @DOD-101 on GitHub (Apr 19, 2024).
Original GitHub issue: https://github.com/aome510/spotify-player/issues/415
Describe the bug
A clear and concise description of what the bug is.
The "spotify_player get key playback" command sometimes returns outdated information, when changing the playback from a TUI client while playing music via the daemon.
To Reproduce
You should see that if you close the window and try to get the playback info again, it will still be displaying the song that was playing before you switched it in the TUI.
Note: Sometimes the playback info will correct itself again after a short while and will from then forward show the right info until repeat step 3 again.
Expected behaviour
The command should be returning what is currently being shown in the TUI, aka what I am hearing.
Log and backtrace
Log of the daemon:
Log of the client:
Environment
Additional context
I think the issue may have to do with the fact that the application doesn't call the spotify api each time. It first tries to get the info from the application itself (see line 94 in
spotify_player/src/cli/client.rs), which could be causing this strange behaviour when using the daemon and a client at the same time.@aome510 commented on GitHub (Apr 20, 2024):
This is intended to speed up the command's latency. The player should be able to infer its playback state most of the time. However, if you control the player's playback using external tool, e.g from other Spotify client, the state may not be up-to-date. I'm well aware of this drawback and will be working on a patch
@DOD-101 commented on GitHub (Apr 20, 2024):
Would it be possible to - perhaps simply in the interim - implement a flag / setting that tells it to always call the API?
@aome510 commented on GitHub (Apr 20, 2024):
yes, but it feels more like a hack than a proper fix
@aome510 commented on GitHub (Apr 20, 2024):
@DOD-101 should be fixed with #418. Can you try the latest
main?@DOD-101 commented on GitHub (Apr 20, 2024):
Sure thing.
@DOD-101 commented on GitHub (Apr 20, 2024):
Alrighty, so after a little bit of testing, I have found the following:
So it's kinda fixed, but at the same time it probably shouldn't take that long to "recognize" the change.
@aome510 commented on GitHub (Apr 20, 2024):
How did you test the change? WDYM by "one changes the song manually in any way"?
@DOD-101 commented on GitHub (Apr 20, 2024):
I cloned the git repo and then cargo build it with only the daemon feature flag added.
Making sure to delete the Arch package and then I ran it form ~/.cargo/bin.
Then I followed the steps outlined in the original post.
I meant that if you either skip to the next song (via the shortcut) or by simply selecting some other song in the tui.
Should have been more clear here: This only applies to changing the song in another client. If one changes the song via the "spotify_player playback next" command it will update almost instantly, as if it just finished playing.
@aome510 commented on GitHub (Apr 20, 2024):
cargo builddoesn't produce the binary in~/.cargo/binthough, it should be inside the repo'starget/debug@DOD-101 commented on GitHub (Apr 20, 2024):
I'm sorry.
I accidentally ran
cargo installinstead ofcargo build(not familiar with rust). My bad.It works like a charm now. Thanks. Keep up the great work.
@aome510 commented on GitHub (Apr 20, 2024):
Great! Thanks for confirming