[GH-ISSUE #136] [Windows] Every keypress is duplicated #58

New issue

Closed

opened 2026-03-02 23:44:09 +03:00 by kerem · 3 comments

kerem commented

2026-03-02 23:44:09 +03:00

Owner

Originally created by @viridivn on GitHub (Feb 16, 2023).
Original GitHub issue: https://github.com/aome510/spotify-player/issues/136

Describe the bug
On windows, every keypress is sent both on the press down, and on the key release. This makes the app near impossible to use as searches can't be made and only even rows can be selected

To Reproduce
cargo install spotify_player on Windows 11
spotify_player.exe (Issue occurs in both cmd.exe and powershell)
Navigate up and down, try searching, etc

Expected behavior
A key is sent to the app once per keypress.

Log and backtrace
Reference log and backtrace, which are usually located in $HOME/.cache/spotify-player/, of a run reproducing the bug.
'spotify-player-23-02-16-17' in the cache directory seems to be an empty file even after using the program

Screenshots
If applicable, add screenshots to help explain your problem.
https://user-images.githubusercontent.com/42524580/219504557-0267b5c6-52ea-441b-b5d5-f29fc40ed41d.mp4

Environment

OS: Windows 11 build 25295
Application version: 0.11.1
Application features: if applicable, provide cargo features used to build with spotify-player: Defaults (Installed with cargo install spotify_player

Additional context
Doesn't appear to happen on my Linux install.

Originally created by @viridivn on GitHub (Feb 16, 2023). Original GitHub issue: https://github.com/aome510/spotify-player/issues/136 **Describe the bug** On windows, every keypress is sent both on the press down, and on the key release. This makes the app near impossible to use as searches can't be made and only even rows can be selected **To Reproduce** `cargo install spotify_player` on Windows 11 `spotify_player.exe` (Issue occurs in both cmd.exe and powershell) Navigate up and down, try searching, etc **Expected behavior** A key is sent to the app once per keypress. **Log and backtrace** Reference log and backtrace, which are usually located in `$HOME/.cache/spotify-player/`, of a run reproducing the bug. 'spotify-player-23-02-16-17' in the cache directory seems to be an empty file even after using the program **Screenshots** If applicable, add screenshots to help explain your problem. https://user-images.githubusercontent.com/42524580/219504557-0267b5c6-52ea-441b-b5d5-f29fc40ed41d.mp4 **Environment** - OS: Windows 11 build 25295 - Application version: 0.11.1 - Application features: if applicable, provide [cargo features](https://doc.rust-lang.org/cargo/reference/features.html) used to build with `spotify-player`: Defaults (Installed with `cargo install spotify_player` **Additional context** Doesn't appear to happen on my Linux install.

kerem

2026-03-02 23:44:09 +03:00

closed this issue
added the
help wanted

bug
labels

kerem commented

2026-03-02 23:44:10 +03:00

Author

Owner

@aome510 commented on GitHub (Feb 20, 2023):

Hi @scarlettekk, I don't have access to windows machine and I'm not too familiar with development on Win, so I couldn't really test/fix this issue. Hopefully, I can in the near future or someone can pick this up.

'spotify-player-23-02-16-17' in the cache directory seems to be an empty file even after using the program

Log file spotify-player-*.log should not empty. I wonder if this is because the app cannot interact with the OS properly.

@aome510 commented on GitHub (Feb 20, 2023): Hi @scarlettekk, I don't have access to windows machine and I'm not too familiar with development on Win, so I couldn't really test/fix this issue. Hopefully, I can in the near future or someone can pick this up. > 'spotify-player-23-02-16-17' in the cache directory seems to be an empty file even after using the program Log file `spotify-player-*.log` should not empty. I wonder if this is because the app cannot interact with the OS properly.

kerem commented

2026-03-02 23:44:10 +03:00

Author

Owner

@viridivn commented on GitHub (Mar 3, 2023):

Can confirm issue is resolved

@viridivn commented on GitHub (Mar 3, 2023): Can confirm issue is resolved

kerem commented

2026-03-02 23:44:10 +03:00

Author

Owner

@aome510 commented on GitHub (Mar 3, 2023):

Thanks. This fix will be included in the upcoming release, which should be released soon!

@aome510 commented on GitHub (Mar 3, 2023): Thanks. This fix will be included in the upcoming release, which should be released soon!

kerem referenced this issue

2026-03-02 23:49:01 +03:00

[PR #58] [MERGED] Remove user:{user} part when parsing URIs #608

kerem referenced this issue

2026-03-14 15:19:45 +03:00

[PR #58] [MERGED] Remove user:{user} part when parsing URIs #1543