ncspot: Thread Error

Thanks again. I have pushed another fix and was able to reproduce it. In my case it successfully recreated the session. The UI was still a little off/out of sync, but after starting playback of another track things were fine. Some minor work remains, but it shouldn’t be as fragile anymore.

Let men know if this fixes it for you. Make sure you pull the current state. I really appreciate all the feedback/reports.

Hi, I still have this issue. It’s pretty easy to reproduce it, just start playing a song, disconnect and reconnect wifi and when press > to play the next song, it won’t play but it doesn’t seem any error in the log:

[2021-06-24][11:20:32] [tokio_util::codec::framed_impl] [TRACE] framed transport flushed
[2021-06-24][11:20:40] [ncspot::spotify] [INFO] loading track: Track((Die Toten Hosen - Ballast der Republik (Some("61whykWjJe29sSbS1c5PX9"))))
[2021-06-24][11:20:40] [ncspot::spotify_worker] [INFO] player loading track: SpotifyId { id: 263116727897776758112800987915867240855, audio_type: Track }
[2021-06-24][11:20:40] [librespot_playback::player] [DEBUG] command=Load(SpotifyId { id: 263116727897776758112800987915867240855, audio_type: Track }, true, 0)
[2021-06-24][11:20:40] [librespot_playback::player] [TRACE] == Stopping sink ==
[2021-06-24][11:20:40] [tokio_util::codec::framed_impl] [TRACE] flushing framed transport
[2021-06-24][11:20:40] [tokio_util::codec::framed_impl] [TRACE] writing; remaining=83
[2021-06-24][11:20:40] [tokio_util::codec::framed_impl] [TRACE] framed transport flushed

I built ncspot locally, i.e. running cargo install ncspot

$ ncspot --version
ncspot 0.7.3

$ cargo --version
cargo 1.52.0 (69767412a 2021-04-21)

Thanks!

Hey there, thanks for the report. So it seems that ncspot can at least detect that the session has died, which is a good first step, but recreating the session seems to fail. Unfortunately, backtrace output is logged to stderr and thus not in the normal debug log. You can log it by appending 2>stderr.log, which will log the backtrace to stderr.log. Would be awesome if you could attach a backtrace the next time it happens.

I am also encountering this error. It is weird that people are getting different panic messages. My error looks like these two, not the other two. I’d also like to point out that in both my log and @tommady’s, there are two [ERROR] messages:

[2020-06-10][21:58:29] [librespot_playback::player] [ERROR] Unable to load audio item.
[2020-06-10][21:58:29] [librespot_core::session] [ERROR] Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }

I wonder if the TCP connection is being reset once the system goes to sleep and librespot cannot handle that? My connection is not usually unstable, but I will always notice this after my computer sleeps. ~(I also remember it happening when my computer hasn’t slept, but I have not yet reproduced this.)~ This will also happen even when my computer has not slept! This theory may or may not still be correct, but it doesn’t only correlate with my laptop sleeping.

On a related note, I have trouble copying the entire stderr message, as it seems to be caught in the TUI, and the terminal intercepts all clicks. Perhaps going forward you should pipe all normal stderr messages to actual stderr? I don’t know if that would be a problematic change, but it would at least help with debugging.

My System:

operating system: Ubuntu 20.04 ncspot version: ncspot 0.1.3 installed via: cargo install ncspot --forced

Hi @theorangepotato I found out the root cause of my reply and maybe can help you too.

the issue belongs to this: https://github.com/librespot-org/librespot/issues/134

and

https://github.com/librespot-org/librespot/pull/206 https://github.com/librespot-org/librespot/pull/427 those two MR fix that, but only when librespot running as a binary itself… not fix in the library…

so my solution is to

1. build the librespot as binary and run it as a daemon
2. run a client who implements the Spotify connect feature to control it

now the mac goes to sleep then wake up, the Spotify session will auto reconnected as well.

so for ncspot this repo, the ways to fix this issue are:

1. implement the reconnection logic itself. (OR)
2. wait for the librespot implement the reconnection logic into the library

hope this helped 🙇

I got the same issue, but run on macos,

but my backtrace says panic on this line https://github.com/librespot-org/librespot/blob/6daa2acd0af7dfe70837592b33bfe9480783f852/playback/src/player.rs#L159

version macos 10.15.4 ncspot 0.1.3 build with below command

cargo build --release --no-default-features --features rodio_backend,cursive/pancurses-backend

steps

1. pause the ncspot with shift p or not pause it goto sleep directly both panic on the same line.
2. put the mac into sleep, with or without the below setting (I tried both, the same result)

energy saver -> put hard disks to sleep when possible

1. wait a while, not too fast to wake the computer up, define too fast: like pressing the sleep button then wake it up immediately, this will not panic and the ncspot will acting normally.

2. then finish the song remains, panic.

debug log debug.log

at [2020-06-09][22:03:11] [ncspot::spotify] [INFO] pause() then at [2020-06-09][22:14:15] [ncspot::spotify] [INFO] play() waiting the remained song finished, then at [2020-06-09][22:14:31] [librespot_playback::player] [ERROR] Unable to load audio item.

hope this helped