[GH-ISSUE #178] Have to restart spotifyd after playing a song #88

New issue

Open

opened 2026-02-28 14:46:57 +03:00 by kerem · 3 comments

kerem commented

2026-02-28 14:46:57 +03:00

Owner

Originally created by @pviotti on GitHub (Dec 1, 2019).
Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/178

Sometimes, after playing a song, it shows the Spotify API reported an error message. So I have to restart spotifyd (systemctl --user restart spotifyd.service), after which it starts working again.
This happens only sometimes, but often enough to be inconvenient. This is the error log I get from spotifyd:

15:45:11 [DEBUG] (1) librespot_core::session: Invalidating session[0]
15:45:11 [DEBUG] (1) librespot_core::session: drop Dispatch
15:45:11 [TRACE] (1) mio::poll: [/home/myuser/.cargo/registry/src/github.com-1ecc6299db9ec823/mio-0.6.19/src/poll.rs:907] deregistering handle with poller
15:45:11 [DEBUG] (1) tokio_reactor: dropping I/O source: 5
15:45:11 [ERROR] Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }

I can't figure out what condition triggers it, but it looks like it's related to this spotifyd issue https://github.com/Spotifyd/spotifyd/issues/156 , which in turns may be related to librespot.

I know spotify-tui is not to blame, but I'm posting this issue so that other users experiencing the same can find some information. (Maybe on spotity-tui's side, a more informative error message can be shown..?)

OS: Arch Linux
spotify-tui: 0.10.0 (AUR package from git, updated today)
spotifyd: 0.2.20

Originally created by @pviotti on GitHub (Dec 1, 2019). Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/178 *Sometimes*, after playing a song, it shows the `Spotify API reported an error` message. So I have to restart spotifyd (`systemctl --user restart spotifyd.service`), after which it starts working again. This happens only sometimes, but often enough to be inconvenient. This is the error log I get from spotifyd: ``` 15:45:11 [DEBUG] (1) librespot_core::session: Invalidating session[0] 15:45:11 [DEBUG] (1) librespot_core::session: drop Dispatch 15:45:11 [TRACE] (1) mio::poll: [/home/myuser/.cargo/registry/src/github.com-1ecc6299db9ec823/mio-0.6.19/src/poll.rs:907] deregistering handle with poller 15:45:11 [DEBUG] (1) tokio_reactor: dropping I/O source: 5 15:45:11 [ERROR] Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" } ``` I can't figure out what condition triggers it, but it looks like it's related to this spotifyd issue https://github.com/Spotifyd/spotifyd/issues/156 , which in turns may be related to librespot. I know spotify-tui is not to blame, but I'm posting this issue so that other users experiencing the same can find some information. (Maybe on spotity-tui's side, a more informative error message can be shown..?) OS: Arch Linux spotify-tui: 0.10.0 (AUR package from git, updated today) spotifyd: 0.2.20

kerem commented

2026-02-28 14:46:58 +03:00

Author

Owner

@Rigellute commented on GitHub (Dec 2, 2019):

Thanks for the info @pviotti

@Rigellute commented on GitHub (Dec 2, 2019): Thanks for the info @pviotti

kerem commented

2026-02-28 14:46:58 +03:00

Author

Owner

@stevensonmt commented on GitHub (Dec 3, 2019):

Think it's actually this issue with librespot: https://github.com/librespot-org/librespot/issues/134

@stevensonmt commented on GitHub (Dec 3, 2019): Think it's actually this issue with librespot: https://github.com/librespot-org/librespot/issues/134

kerem commented

2026-02-28 14:46:58 +03:00

Author

Owner

@sputnick1124 commented on GitHub (Dec 13, 2019):

Unfortunately the errors we get back from rspotify are lacking somewhat. Getting anything more than the HTTP error code seems to be problematic. I definitely agree that better error handling/reporting is a goal worth devoting attention to, however.

@sputnick1124 commented on GitHub (Dec 13, 2019): Unfortunately the errors we get back from rspotify are lacking somewhat. Getting anything more than the HTTP error code seems to be problematic. I definitely agree that better error handling/reporting is a goal worth devoting attention to, however.