Closed DOD-101 closed 3 months ago
I think the issue may have to do with the fact that the application doesn't call the spotify api each time
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
@DOD-101 should be fixed with #418. Can you try the latest main
?
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"?
How did you test the change?
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.
WDYM by "one changes the song manually in any way"?
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.
Making sure to delete the Arch package and then I ran it form ~/.cargo/bin.
cargo build
doesn't produce the binary in ~/.cargo/bin
though, it should be inside the repo's target/debug
I'm sorry.
I accidentally ran cargo install
instead of cargo build
(not familiar with rust). My bad.
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.