librespot: librespot crashing after x songs

Since a few days, librespot is crashing after playing a number of songs from a playlist.

All was working before and nothing has changed on my side, so my guess is, that spotify must have changed something.

Steps to reproduce:

Start a playlist
if you don’t want to wait, skip every song to the last part and let it change the track, go on like this for a couple of tracks (for me it is between 9 and 15 tracks) it eventually crashes

Here is a verbose log from the crash:

DEBUG:librespot_playback::player: command=Load(SpotifyId(u128!(218675386531455298211524659961312007164)), true, 0)
INFO:librespot_playback::player: Loading track "I Am" with Spotify URI "spotify:track:50qLAF3XgfhtaCGDKT4Kks"
DEBUG:librespot_audio::fetch: Downloading file 3c1d6b8f30aaa1ba57612f5aeb4f4a498990562a
TRACE:librespot_audio::fetch: requesting chunk 0
ERROR:librespot_core::channel: channel error: 2 1
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: ChannelError', libcore/result.rs:945:5
stack backtrace:
   0:   0x9b7333 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h4ef6490c84cef3d0
                       at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:   0x9b108f - std::sys_common::backtrace::_print::hea150ee4f33bb5de
                       at libstd/sys_common/backtrace.rs:71
   2:   0x9b5da3 - std::panicking::default_hook::{{closure}}::h6c4396ff5bd61d89
                       at libstd/sys_common/backtrace.rs:59
                       at libstd/panicking.rs:380
   3:   0x9b5987 - std::panicking::default_hook::h0f6cb16cf06a0198
                       at libstd/panicking.rs:396
   4:   0x9b6247 - std::panicking::rust_panic_with_hook::h2207195920ffa55f
                       at libstd/panicking.rs:576
   5:   0x9b60ab - std::panicking::begin_panic::h8d43a09cf6d6e5f1
                       at libstd/panicking.rs:537
   6:   0x9b602f - std::panicking::begin_panic_fmt::hd9afc94159ee9735
                       at libstd/panicking.rs:521
   7:   0x9b5fc7 - rust_begin_unwind
                       at libstd/panicking.rs:497
   8:   0xa03e57 - core::panicking::panic_fmt::h0bd854df201d1baf
                       at libcore/panicking.rs:71
   9:   0x56290f - core::result::unwrap_failed::h0e273f2ef825e9af
  10:   0x55d85f - librespot_playback::player::PlayerInternal::run::h296c59bd7682ffbf
  11:   0x4dd4bb - std::sys_common::backtrace::__rust_begin_short_backtrace::h0ef34e9728d818f7
  12:   0x4f0a03 - std::panicking::try::do_call::h55970923d54b3006
  13:   0x9c5673 - __rust_maybe_catch_panic
                       at libpanic_unwind/lib.rs:102
  14:   0x4f292b - <F as alloc::boxed::FnBox<A>>::call_box::h6c97a59281f0cee4
  15:   0x9bc2df - std::sys::unix::thread::Thread::new::thread_start::hb1d1727b173caaf8
                       at /checkout/src/liballoc/boxed.rs:798
                       at libstd/sys_common/thread.rs:24
                       at libstd/sys/unix/thread.rs:90
DEBUG:librespot_playback::player: drop Player[0]
DEBUG:librespot_core::session: Session[0] strong=2 weak=4

i tried this with pipe backend and alsa-backend on a raspberry pi 3. It crashes with both backends. I do not have pulseaudio installed.

Also tried this with disabled cache - still crashing 😦

EDIT: i use a self-compiled binary of the latest version, but i also checked out the pre-compiled raspotify binary and some older versions of librespot from the last 2 months which i had on backup. they all have the same behavior.

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 1
Comments: 26 (8 by maintainers)

Most upvoted comments

The desktop client (and probably the mobile one too) download audio files over HTTP, whereas librespot downloads them using the same TCP socket used for everything else. It is possible Spotify is slowing shutting down the latter as they move to some new CDN.

Fixing this would require some more reverse engineering, to figure out how the client learns about the URL to use to download audio files.

My spotify-analyze scripts would be the first step for this. Additionally the desktop client can be started in verbose mode, in which case it prints the URL to the logs. You should compare those logs with the packet dumps, see if any identifier matches.

Does anyone know if speakers which were shipped with Spotify support ~3/4 years ago still work? I originally used their firmware to figure out the protocol.

plietar on May 9, 2018

I can confirm these delays too. If you start a song, album or playlist from the app (desktop mac and android here) there is a 10 second delay before the song starts playing on librespot.

Maybe we should open a new bug report specifically for this problem, as i am not sure this is connected to the crashes.

kutmasterk on May 9, 2018

So, as of today i cannot reproduce the crashes anymore. I just played 30 tracks without interruption.

The only thing useful i have found is this: https://github.com/spotify/web-api/issues/859#issuecomment-386214823

As of this month spotify has enabled a load balancer on their google provided distribution network and now requires a “Content-Length header” set for requests. This is a bugreport for the spotify web-api, but i am not sure if librespot is even using this api.

kutmasterk on May 9, 2018

It may be worth nothing that with libspotify, periods of random ChannelErrors were not unheard of and would correspond to something being temporarily broken at Spotify’s end. I guess the take-away here is that we don’t want to crash but I think there’s already an issue for tracking improvements to this sort of thing.

kingosticks on May 17, 2018