-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"spotify_player get key playback" sometimes returns outdated information #415
Comments
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 |
Would it be possible to - perhaps simply in the interim - implement a flag / setting that tells it to always call the API? |
yes, but it feels more like a hack than a proper fix |
Resolves #415 ## Changes - update player's playback state upon receiving new player event from the integrated client - move `ClientRequest` and `PlayerRequest` from `event` module to `client::request` module - clean up client request handling codes, update comments/documentations
Sure thing. |
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. |
How did you test the change? WDYM by "one changes the song manually in any way"? |
I cloned the git repo and then cargo build it with only the daemon feature flag added.
I meant that if you either skip to the next song (via the shortcut) or by simply selecting some other song in the tui. |
|
I'm sorry. It works like a charm now. Thanks. Keep up the great work. |
Great! Thanks for confirming |
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.The text was updated successfully, but these errors were encountered: