starred/spotify-player

Fork 0

mirror of https://github.com/aome510/spotify-player.git synced 2026-04-26 09:25:49 +03:00

[GH-ISSUE #181] MPRIS/playerctl very slow to update after track changes (Linux) #1027

New issue

Closed

opened 2026-03-14 13:04:08 +03:00 by kerem · 5 comments

kerem commented

2026-03-14 13:04:08 +03:00

Owner

Originally created by @lilacpixel on GitHub (Apr 22, 2023).
Original GitHub issue: https://github.com/aome510/spotify-player/issues/181

Describe the bug
When the current track changes, there is no delay in playing audio, and the spotify-player interface updates almost immediately, but MPRIS takes several seconds (or longer) to report the details of the new track. Running playerctl metadata will continue to show metadata for the previous track, sometimes for as long as 8-10 seconds into the new track. This delay isn't seen with other applications that report current audio to MPRIS (Firefox, ncspot, mpv, etc). Is it hanging on the request for album art?

(Edit: I may have underestimated the delay—just timed the latest track change delay at a little over 30 seconds, which is a pretty decent chunk of the whole song!)

To Reproduce

Queue up a playlist of any type with multiple tracks and play.
Advance to the next track and wait for audio to begin playing.
Note delay between audio start and MPRIS response (easily observed when using a status bar).

Expected behavior
MPRIS should update with new metadata immediately after track changes (< 1 second).

Log and backtrace

2023-04-22T16:46:03.940707Z  INFO spotify_player::streaming: Got an event from the integrated player: EndOfTrack { play_request_id: 29, track_id: SpotifyId { id: 290439059944025163674801041118175308858, audio_type: Track } }
2023-04-22T16:46:03.940901Z  INFO spotify_player::streaming: Got an event from the integrated player: Changed { old_track_id: SpotifyId { id: 290439059944025163674801041118175308858, audio_type: Track }, new_track_id: SpotifyId { id: 105841330911538712758672755311808310056, audio_type: Track } }
2023-04-22T16:46:03.940975Z  INFO spotify_player::streaming: Got an event from the integrated player: Playing { play_request_id: 30, track_id: SpotifyId { id: 105841330911538712758672755311808310056, audio_type: Track }, position_ms: 0, duration_ms: 210120 }
2023-04-22T16:46:04.294885Z  INFO client_request{request=GetCurrentPlayback}: spotify_player::client: Retrieving an image from url: https://i.scdn.co/image/ab67616d0000b273c06722e2f1bfc0f938866fdb
2023-04-22T16:46:04.411204Z  INFO client_request{request=GetCurrentPlayback}: spotify_player::client: successfully handled the client request, took: 470ms
2023-04-22T16:46:04.562165Z  INFO client_request{request=GetCurrentPlayback}: spotify_player::client: successfully handled the client request, took: 620ms
2023-04-22T16:46:04.926200Z  INFO client_request{request=GetCurrentPlayback}: spotify_player::client: Saving the retrieved image into /home/cari/.cache/spotify-player/image/PRISMATICS-TENDRE-cover.jpg
2023-04-22T16:46:04.926622Z  INFO client_request{request=GetCurrentPlayback}: spotify_player::client: Retrieving an image from the file: /home/cari/.cache/spotify-player/image/PRISMATICS-TENDRE-cover.jpg
2023-04-22T16:46:04.934687Z  INFO client_request{request=GetCurrentPlayback}: spotify_player::client: successfully handled the client request, took: 993ms

Environment

OS: Fedora Linux 38
Application version: spotify_player 0.13.1
Application features: Installed with cargo install --git https://github.com/aome510/spotify-player.git --features sixel

MPRIS quirks aside, thanks for a great application—really nice to have feature parity with the official client in a lightweight terminal app! 😺

Originally created by @lilacpixel on GitHub (Apr 22, 2023). Original GitHub issue: https://github.com/aome510/spotify-player/issues/181 **Describe the bug** When the current track changes, there is no delay in playing audio, and the spotify-player interface updates almost immediately, but MPRIS takes several seconds (or longer) to report the details of the new track. Running `playerctl metadata` will continue to show metadata for the previous track, sometimes for as long as 8-10 seconds into the new track. This delay isn't seen with other applications that report current audio to MPRIS (Firefox, ncspot, mpv, etc). Is it hanging on the request for album art? (Edit: I may have underestimated the delay—just timed the latest track change delay at a little over 30 seconds, which is a pretty decent chunk of the whole song!) **To Reproduce** 1. Queue up a playlist of any type with multiple tracks and play. 2. Advance to the next track and wait for audio to begin playing. 3. Note delay between audio start and MPRIS response (easily observed when using a status bar). **Expected behavior** MPRIS should update with new metadata immediately after track changes (< 1 second). **Log and backtrace** ``` 2023-04-22T16:46:03.940707Z INFO spotify_player::streaming: Got an event from the integrated player: EndOfTrack { play_request_id: 29, track_id: SpotifyId { id: 290439059944025163674801041118175308858, audio_type: Track } } 2023-04-22T16:46:03.940901Z INFO spotify_player::streaming: Got an event from the integrated player: Changed { old_track_id: SpotifyId { id: 290439059944025163674801041118175308858, audio_type: Track }, new_track_id: SpotifyId { id: 105841330911538712758672755311808310056, audio_type: Track } } 2023-04-22T16:46:03.940975Z INFO spotify_player::streaming: Got an event from the integrated player: Playing { play_request_id: 30, track_id: SpotifyId { id: 105841330911538712758672755311808310056, audio_type: Track }, position_ms: 0, duration_ms: 210120 } 2023-04-22T16:46:04.294885Z INFO client_request{request=GetCurrentPlayback}: spotify_player::client: Retrieving an image from url: https://i.scdn.co/image/ab67616d0000b273c06722e2f1bfc0f938866fdb 2023-04-22T16:46:04.411204Z INFO client_request{request=GetCurrentPlayback}: spotify_player::client: successfully handled the client request, took: 470ms 2023-04-22T16:46:04.562165Z INFO client_request{request=GetCurrentPlayback}: spotify_player::client: successfully handled the client request, took: 620ms 2023-04-22T16:46:04.926200Z INFO client_request{request=GetCurrentPlayback}: spotify_player::client: Saving the retrieved image into /home/cari/.cache/spotify-player/image/PRISMATICS-TENDRE-cover.jpg 2023-04-22T16:46:04.926622Z INFO client_request{request=GetCurrentPlayback}: spotify_player::client: Retrieving an image from the file: /home/cari/.cache/spotify-player/image/PRISMATICS-TENDRE-cover.jpg 2023-04-22T16:46:04.934687Z INFO client_request{request=GetCurrentPlayback}: spotify_player::client: successfully handled the client request, took: 993ms ``` **Environment** - OS: Fedora Linux 38 - Application version: spotify_player 0.13.1 - Application features: Installed with `cargo install --git https://github.com/aome510/spotify-player.git --features sixel` MPRIS quirks aside, thanks for a great application—really nice to have feature parity with the official client in a lightweight terminal app! 😺

kerem

2026-03-14 13:04:08 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-14 13:04:24 +03:00

Author

Owner

@aome510 commented on GitHub (Apr 22, 2023):

Thanks for the kind words. I didn't have this experience with my other Ubuntu machine. Let me try again later this week to see if I can reproduce the issue.

@aome510 commented on GitHub (Apr 22, 2023): Thanks for the kind words. I didn't have this experience with my other Ubuntu machine. Let me try again later this week to see if I can reproduce the issue.

kerem commented

2026-03-14 13:04:29 +03:00

Author

Owner

@sewnie commented on GitHub (Apr 23, 2023):

on my machine it takes ~390ms.

@sewnie commented on GitHub (Apr 23, 2023): on my machine it takes ~390ms.

kerem commented

2026-03-14 13:04:34 +03:00

Author

Owner

@aome510 commented on GitHub (Apr 24, 2023):

@lunamode I just tested on ubuntu machine and the delay was about 1s. I didn't get any long delays like 8-10s. I don't really know how this issue happens. The log looks normal to me.

@aome510 commented on GitHub (Apr 24, 2023): @lunamode I just tested on ubuntu machine and the delay was about 1s. I didn't get any long delays like 8-10s. I don't really know how this issue happens. The log looks normal to me.

kerem commented

2026-03-14 13:04:39 +03:00

Author

Owner

@aome510 commented on GitHub (May 8, 2023):

@lunamode do u still encounter this issue?

@aome510 commented on GitHub (May 8, 2023): @lunamode do u still encounter this issue?

kerem commented

2026-03-14 13:04:44 +03:00

Author

Owner

@lilacpixel commented on GitHub (May 9, 2023):

@lunamode do u still encounter this issue?

I'm now seeing delays of just a second or so, similar to what you encountered on Ubuntu. No more huge delays of 10+ seconds. I'm guessing that whatever I was seeing before was just some temporary weirdness, maybe related to the Fedora 38 upgrade…? I appreciate you taking the time to test on your end—thanks so much! ☺️

@lilacpixel commented on GitHub (May 9, 2023): > @lunamode do u still encounter this issue? I'm now seeing delays of just a second or so, similar to what you encountered on Ubuntu. No more huge delays of 10+ seconds. I'm guessing that whatever I was seeing before was just some temporary weirdness, maybe related to the Fedora 38 upgrade…? I appreciate you taking the time to test on your end—thanks so much! ☺️