[GH-ISSUE #350] Lock-up when connection is reset on Spotify's end #233

New issue

Closed

opened 2026-02-27 19:29:33 +03:00 by kerem · 22 comments

kerem commented 2026-02-27 19:29:33 +03:00

Owner

Copy link

Originally created by @matthijskooijman on GitHub (Jul 13, 2019).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/350

I've seen librespot lock up after some time, disappearing from the discovered devices list (no longer responding to mdns requests). I'm not sure if it actually interrupted playing or just hung up while nothing was playing.

This was observed with a self-compiled git master version (github.com/librespot-org/librespot@4e3576ba7c)

This seems to be similar to #247 and #215, though I'm not so sure this is really the same bug. I don't have any meaningful backtrace in the logfile, for example. Also I have quite some details, so it is probably better to have a separate issue unless we can confirm that they are indeed the same.

In the log file, I see:

INFO:librespot_playback::player: Track "Money" loaded
ERROR:librespot_core::session: Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }

It seems librespot has stopped reading from the mdns socket:

pi@Kitchen:~ $ sudo netstat -lnp4|grep librespot
tcp        2      0 0.0.0.0:40719           0.0.0.0:*               LISTEN      918/librespot       
udp   135616      0 0.0.0.0:5353            0.0.0.0:*                           918/librespot

strace shows that no syscalls are happening:

strace: Process 918 attached
futex(0x757ff318, FUTEX_WAIT, 7632, NULLstrace: Process 918 detached
 <detached ...>

gdb also suggests that all threads are locked up:

(gdb) thread apply all bt                                                                                                                                     
Thread 1 (Thread 0x76f92340 (LWP 918)):
#0  0x76cdc464 in pthread_join (threadid=<optimized out>, thread_return=0x0) at pthread_join.c:90
#1  0x009b0b70 in std::sys::unix::thread::Thread::join::h07edb28013cf027c () at libstd/sys/unix/thread.rs:176
#2  0x00564984 in _$LT$std..thread..JoinHandle$LT$T$GT$$GT$::join::hf42ff97141008219 ()
#3  0x0055a260 in _$LT$librespot_playback..player..Player$u20$as$u20$core..ops..drop..Drop$GT$::drop::hac48e437737a6f07 ()
#4  0x004e46b0 in core::ptr::drop_in_place::h7e33a9ed9b5ca32a ()
#5  0x004e4c7c in core::ptr::drop_in_place::hb62ed06addeb6e0b ()
#6  0x008cdd24 in tokio::executor::current_thread::scheduler::release_node::h436b9d48d651653a ()
#7  0x008d0e64 in _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::with::ha280e7894e4db392 ()
#8  0x008ce278 in _$LT$tokio..executor..current_thread..scheduler..Scheduler$LT$U$GT$$GT$::tick::hd8a23f66e53862f4 ()
#9  0x008c4b6c in _$LT$scoped_tls..ScopedKey$LT$T$GT$$GT$::set::hc32e64633834effa ()
#10 0x008d1604 in _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::with::hf2008c182fa53f44 ()
#11 0x008d0cd0 in _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::with::h613425a247458594 ()
#12 0x008d10b0 in _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::with::hb0b1f89fcde726c3 ()
#13 0x008ccc0c in tokio_core::reactor::Core::poll::h854a3e1b89a82b9b ()
#14 0x004e23b8 in tokio_core::reactor::Core::run::ha4d6f8476bb012d1 ()
#15 0x004dc580 in librespot::main::h95a6d9f6a736a6db ()
#16 0x00b8b940 in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 2 (Thread 0x767ff2b0 (LWP 926)):
#0  0x76de2704 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
#1  0x0090a320 in mio::sys::unix::epoll::Selector::select::h060b379467f466c7 ()                                                                               
#2  0x00908650 in mio::poll::Poll::poll1::hfaa8e74388b143cd ()
#3  0x00907f98 in mio::poll::Poll::poll::h659ee91e412450f3 ()
#4  0x008fbb60 in tokio_reactor::Reactor::turn::h83e3d5bb7567c2fc ()
#5  0x009043c0 in tokio_reactor::background::run::h28e75bf0a40d4e9c ()
#6  0x008ff4a0 in std::sys_common::backtrace::__rust_begin_short_backtrace::hbf7db8b2dd117737 ()                                                              
#7  0x00905e60 in std::panicking::try::do_call::h8dfef3beef5bc05f ()
#8  0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105
#9  0x00901988 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::ha24a3621df7222f9 ()                                                          
#10 0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648                                                                            
#11 std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24                                                             
#12 0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90                                     
#13 0x76cdafc4 in start_thread (arg=0x767ff2b0) at pthread_create.c:458
#14 0x76de2038 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76 from /lib/arm-linux-gnueabihf/libc.so.6                                                  
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 3 (Thread 0x761ff2b0 (LWP 6252)):                                                                                                                      
#0  0x76ce19a4 in __pthread_cond_wait (cond=0x7681e390, mutex=0x7681b798) at pthread_cond_wait.c:188                                                          
#1  0x009a75c4 in std::sys::unix::condvar::Condvar::wait::hab93781440f55022 () at libstd/sys/unix/condvar.rs:78                                               
#2  std::sys_common::condvar::Condvar::wait::hda28562b419be3ea () at libstd/sys_common/condvar.rs:51                                                          
#3  std::sync::condvar::Condvar::wait::ha0917b1f460848fe () at libstd/sync/condvar.rs:214                                                                     
#4  std::thread::park::h93884c2ad9e85a2d () at libstd/thread/mod.rs:803                                                                                       
#5  0x009b034c in std::sync::mpsc::blocking::WaitToken::wait::hb4820b1cfd0e3ab9 () at libstd/sync/mpsc/blocking.rs:81                                         
#6  0x0056ac50 in _$LT$std..sync..mpsc..stream..Packet$LT$T$GT$$GT$::recv::h0d77bae4424c2898 ()                                                               
#7  0x0057fa70 in _$LT$std..sync..mpsc..Receiver$LT$T$GT$$GT$::recv::h8d3e9d021d799c3c ()                                                                     
#8  0x0055a76c in librespot_playback::player::PlayerInternal::run::hedda082537cecf78 ()                                                                       
#9  0x004fb12c in std::sys_common::backtrace::__rust_begin_short_backtrace::hb57c86e1fbda9cc9 ()                                                              
#10 0x004e9150 in std::panicking::try::do_call::hd65e9edeebabae0e ()
#11 0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105
#12 0x004fd578 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h3a3c2b783a091036 ()
#13 0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT
$A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648
#14 std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24
---Type <return> to continue, or q <return> to quit---
#15 0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90
#16 0x76cdafc4 in start_thread (arg=0x761ff2b0) at pthread_create.c:458
#17 0x76de2038 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0x757ff2b0 (LWP 7632)):
#0  0x76ce19a4 in __pthread_cond_wait (cond=0x7520f000, mutex=0x75215030) at pthread_cond_wait.c:188                                                          
#1  0x00920f4c in futures::task_impl::std::ThreadNotify::park::h7b4e63dd494d5597 ()                                                                           
#2  0x0056c98c in _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::with::hf6072a215a39b3b8 ()                                                                  
#3  0x00566570 in futures::future::Future::wait::h8064970af9245539 ()                                                                                         
#4  0x0055c678 in librespot_playback::player::PlayerInternal::run::hedda082537cecf78 ()                                                                       
#5  0x004fb12c in std::sys_common::backtrace::__rust_begin_short_backtrace::hb57c86e1fbda9cc9 ()                                                              
#6  0x004e9150 in std::panicking::try::do_call::hd65e9edeebabae0e ()                                                                                          
#7  0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105
#8  0x004fd578 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h3a3c2b783a091036 ()                                                          
#9  0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT
$A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648                                                                            
#10 std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24                                                             
#11 0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90                                     
#12 0x76cdafc4 in start_thread (arg=0x757ff2b0) at pthread_create.c:458                                                                                       
#13 0x76de2038 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76 from /lib/arm-linux-gnueabihf/libc.so.6                                                  
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


Thread 5 (Thread 0x74dff2b0 (LWP 26956)):                                                                                                                     
#0  0x76ce19a4 in __pthread_cond_wait (cond=0x7681e5d0, mutex=0x76948ea0) at pthread_cond_wait.c:188
#1  0x009a75c4 in std::sys::unix::condvar::Condvar::wait::hab93781440f55022 () at libstd/sys/unix/condvar.rs:78
#2  std::sys_common::condvar::Condvar::wait::hda28562b419be3ea () at libstd/sys_common/condvar.rs:51                                                          
#3  std::sync::condvar::Condvar::wait::ha0917b1f460848fe () at libstd/sync/condvar.rs:214                                                                      
---Type <return> to continue, or q <return> to quit---                                                                                                        
#4  std::thread::park::h93884c2ad9e85a2d () at libstd/thread/mod.rs:803                                                                                       
#5  0x009b034c in std::sync::mpsc::blocking::WaitToken::wait::hb4820b1cfd0e3ab9 () at libstd/sync/mpsc/blocking.rs:81
#6  0x00919fec in _$LT$std..sync..mpsc..oneshot..Packet$LT$T$GT$$GT$::recv::h10911dd8ed02a40b ()                                                              
#7  0x00911e1c in _$LT$std..sync..mpsc..Receiver$LT$T$GT$$GT$::recv::h86a65277c2302820 ()
#8  0x0090f83c in futures_cpupool::Inner::work::hc3d513a7f0b1bfdb ()                                                                                          
#9  0x00910c88 in std::sys_common::backtrace::__rust_begin_short_backtrace::h41985cfd798e9ad4 ()
#10 0x009114e0 in std::panicking::try::do_call::h954acf9a59e0fa2f ()
#11 0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105
#12 0x009112d0 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h1a23aeeec05d132e ()
#13 0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT
$A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648
#14 std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24
#15 0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90
#16 0x76cdafc4 in start_thread (arg=0x74dff2b0) at pthread_create.c:458
Backtrace stopped: Cannot access memory at address 0x14

Thread 6 (Thread 0x75dfd2b0 (LWP 26957)):                                                                                                                     
#0  0x76ce4f40 in __lll_lock_wait (futex=futex@entry=0x76948e88, private=0) at lowlevellock.c:43                                                              
#1  0x76cddbd4 in __GI___pthread_mutex_lock (mutex=0x76948e88) at pthread_mutex_lock.c:80                                                                     
#2  0x0090f814 in futures_cpupool::Inner::work::hc3d513a7f0b1bfdb ()
#3  0x00910c88 in std::sys_common::backtrace::__rust_begin_short_backtrace::h41985cfd798e9ad4 ()                                                              
#4  0x009114e0 in std::panicking::try::do_call::h954acf9a59e0fa2f ()                                                                                          
#5  0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105                                                                                   
#6  0x009112d0 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h1a23aeeec05d132e ()                                                          
#7  0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT
$A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648                                                                            
#8  std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24                                                             
#9  0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90                                     
#10 0x76cdafc4 in start_thread (arg=0x75dfd2b0) at pthread_create.c:458                                                                                       
Backtrace stopped: Cannot access memory at address 0x14     

                                                                       
Thread 7 (Thread 0x75ffe2b0 (LWP 26958)):              
#0  0x76ce4f40 in __lll_lock_wait (futex=futex@entry=0x76948e88, private=0) at lowlevellock.c:43
#1  0x76cddbd4 in __GI___pthread_mutex_lock (mutex=0x76948e88) at pthread_mutex_lock.c:80
#2  0x0090f814 in futures_cpupool::Inner::work::hc3d513a7f0b1bfdb ()
#3  0x00910c88 in std::sys_common::backtrace::__rust_begin_short_backtrace::h41985cfd798e9ad4 ()
#4  0x009114e0 in std::panicking::try::do_call::h954acf9a59e0fa2f ()
#5  0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105
#6  0x009112d0 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h1a23aeeec05d132e ()
#7  0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT
$A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648
#8  std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24
#9  0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90
#10 0x76cdafc4 in start_thread (arg=0x75ffe2b0) at pthread_create.c:458
Backtrace stopped: Cannot access memory at address 0x14
                                                                                                                                                              
Thread 8 (Thread 0x747ff2b0 (LWP 26959)):                                                                                                                     
#0  0x76ce4f40 in __lll_lock_wait (futex=futex@entry=0x76948e88, private=0) at lowlevellock.c:43                                                              
#1  0x76cddbd4 in __GI___pthread_mutex_lock (mutex=0x76948e88) at pthread_mutex_lock.c:80                                                                     
#2  0x0090f814 in futures_cpupool::Inner::work::hc3d513a7f0b1bfdb ()                                                                                          
#3  0x00910c88 in std::sys_common::backtrace::__rust_begin_short_backtrace::h41985cfd798e9ad4 ()                                                              
#4  0x009114e0 in std::panicking::try::do_call::h954acf9a59e0fa2f ()                                                                                          
#5  0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105                                                                                   
#6  0x009112d0 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h1a23aeeec05d132e ()                                                          
#7  0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT
$A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648                                                                            
#8  std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24                                                             
#9  0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90                                     
#10 0x76cdafc4 in start_thread (arg=0x747ff2b0) at pthread_create.c:458                                                                                       
Backtrace stopped: Cannot access memory at address 0x14

(gdb) info threads
  Id   Target Id         Frame 
* 1    Thread 0x76f92340 (LWP 918) "librespot" 0x76cdc464 in pthread_join (threadid=<optimized out>, thread_return=0x0) at pthread_join.c:90
  2    Thread 0x767ff2b0 (LWP 926) "librespot" 0x76de2704 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
  3    Thread 0x761ff2b0 (LWP 6252) "librespot" 0x76ce19a4 in __pthread_cond_wait (cond=0x7681e390, mutex=0x7681b798) at pthread_cond_wait.c:188
  4    Thread 0x757ff2b0 (LWP 7632) "librespot" 0x76ce19a4 in __pthread_cond_wait (cond=0x7520f000, mutex=0x75215030) at pthread_cond_wait.c:188
  5    Thread 0x74dff2b0 (LWP 26956) "hyper-dns0" 0x76ce19a4 in __pthread_cond_wait (cond=0x7681e5d0, mutex=0x76948ea0) at pthread_cond_wait.c:188
  6    Thread 0x75dfd2b0 (LWP 26957) "hyper-dns1" 0x76ce4f40 in __lll_lock_wait (futex=futex@entry=0x76948e88, private=0) at lowlevellock.c:43
  7    Thread 0x75ffe2b0 (LWP 26958) "hyper-dns2" 0x76ce4f40 in __lll_lock_wait (futex=futex@entry=0x76948e88, private=0) at lowlevellock.c:43
  8    Thread 0x747ff2b0 (LWP 26959) "hyper-dns3" 0x76ce4f40 in __lll_lock_wait (futex=futex@entry=0x76948e88, private=0) at lowlevellock.c:43

I made a core dump file. If it helps, I can share it (but I'm a bit hesitant, since I'm not sure if there's sensitive credentials in there).

Originally created by @matthijskooijman on GitHub (Jul 13, 2019). Original GitHub issue: https://github.com/librespot-org/librespot/issues/350 I've seen librespot lock up after some time, disappearing from the discovered devices list (no longer responding to mdns requests). I'm not sure if it actually interrupted playing or just hung up while nothing was playing. This was observed with a self-compiled git master version (https://github.com/librespot-org/librespot/commit/4e3576ba7c6146cf68e1953daeec929d619b26b1) This seems to be similar to #247 and #215, though I'm not so sure this is really the same bug. I don't have any meaningful backtrace in the logfile, for example. Also I have quite some details, so it is probably better to have a separate issue unless we can confirm that they are indeed the same. In the log file, I see: ``` INFO:librespot_playback::player: Track "Money" loaded ERROR:librespot_core::session: Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" } ``` It seems librespot has stopped reading from the mdns socket: ``` pi@Kitchen:~ $ sudo netstat -lnp4|grep librespot tcp 2 0 0.0.0.0:40719 0.0.0.0:* LISTEN 918/librespot udp 135616 0 0.0.0.0:5353 0.0.0.0:* 918/librespot ``` strace shows that no syscalls are happening: ``` strace: Process 918 attached futex(0x757ff318, FUTEX_WAIT, 7632, NULLstrace: Process 918 detached <detached ...> ``` gdb also suggests that all threads are locked up: ``` (gdb) thread apply all bt Thread 1 (Thread 0x76f92340 (LWP 918)): #0 0x76cdc464 in pthread_join (threadid=<optimized out>, thread_return=0x0) at pthread_join.c:90 #1 0x009b0b70 in std::sys::unix::thread::Thread::join::h07edb28013cf027c () at libstd/sys/unix/thread.rs:176 #2 0x00564984 in _$LT$std..thread..JoinHandle$LT$T$GT$$GT$::join::hf42ff97141008219 () #3 0x0055a260 in _$LT$librespot_playback..player..Player$u20$as$u20$core..ops..drop..Drop$GT$::drop::hac48e437737a6f07 () #4 0x004e46b0 in core::ptr::drop_in_place::h7e33a9ed9b5ca32a () #5 0x004e4c7c in core::ptr::drop_in_place::hb62ed06addeb6e0b () #6 0x008cdd24 in tokio::executor::current_thread::scheduler::release_node::h436b9d48d651653a () #7 0x008d0e64 in _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::with::ha280e7894e4db392 () #8 0x008ce278 in _$LT$tokio..executor..current_thread..scheduler..Scheduler$LT$U$GT$$GT$::tick::hd8a23f66e53862f4 () #9 0x008c4b6c in _$LT$scoped_tls..ScopedKey$LT$T$GT$$GT$::set::hc32e64633834effa () #10 0x008d1604 in _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::with::hf2008c182fa53f44 () #11 0x008d0cd0 in _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::with::h613425a247458594 () #12 0x008d10b0 in _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::with::hb0b1f89fcde726c3 () #13 0x008ccc0c in tokio_core::reactor::Core::poll::h854a3e1b89a82b9b () #14 0x004e23b8 in tokio_core::reactor::Core::run::ha4d6f8476bb012d1 () #15 0x004dc580 in librespot::main::h95a6d9f6a736a6db () #16 0x00b8b940 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 2 (Thread 0x767ff2b0 (LWP 926)): #0 0x76de2704 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84 #1 0x0090a320 in mio::sys::unix::epoll::Selector::select::h060b379467f466c7 () #2 0x00908650 in mio::poll::Poll::poll1::hfaa8e74388b143cd () #3 0x00907f98 in mio::poll::Poll::poll::h659ee91e412450f3 () #4 0x008fbb60 in tokio_reactor::Reactor::turn::h83e3d5bb7567c2fc () #5 0x009043c0 in tokio_reactor::background::run::h28e75bf0a40d4e9c () #6 0x008ff4a0 in std::sys_common::backtrace::__rust_begin_short_backtrace::hbf7db8b2dd117737 () #7 0x00905e60 in std::panicking::try::do_call::h8dfef3beef5bc05f () #8 0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105 #9 0x00901988 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::ha24a3621df7222f9 () #10 0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648 #11 std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24 #12 0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90 #13 0x76cdafc4 in start_thread (arg=0x767ff2b0) at pthread_create.c:458 #14 0x76de2038 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76 from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 3 (Thread 0x761ff2b0 (LWP 6252)): #0 0x76ce19a4 in __pthread_cond_wait (cond=0x7681e390, mutex=0x7681b798) at pthread_cond_wait.c:188 #1 0x009a75c4 in std::sys::unix::condvar::Condvar::wait::hab93781440f55022 () at libstd/sys/unix/condvar.rs:78 #2 std::sys_common::condvar::Condvar::wait::hda28562b419be3ea () at libstd/sys_common/condvar.rs:51 #3 std::sync::condvar::Condvar::wait::ha0917b1f460848fe () at libstd/sync/condvar.rs:214 #4 std::thread::park::h93884c2ad9e85a2d () at libstd/thread/mod.rs:803 #5 0x009b034c in std::sync::mpsc::blocking::WaitToken::wait::hb4820b1cfd0e3ab9 () at libstd/sync/mpsc/blocking.rs:81 #6 0x0056ac50 in _$LT$std..sync..mpsc..stream..Packet$LT$T$GT$$GT$::recv::h0d77bae4424c2898 () #7 0x0057fa70 in _$LT$std..sync..mpsc..Receiver$LT$T$GT$$GT$::recv::h8d3e9d021d799c3c () #8 0x0055a76c in librespot_playback::player::PlayerInternal::run::hedda082537cecf78 () #9 0x004fb12c in std::sys_common::backtrace::__rust_begin_short_backtrace::hb57c86e1fbda9cc9 () #10 0x004e9150 in std::panicking::try::do_call::hd65e9edeebabae0e () #11 0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105 #12 0x004fd578 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h3a3c2b783a091036 () #13 0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT $A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648 #14 std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24 ---Type <return> to continue, or q <return> to quit--- #15 0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90 #16 0x76cdafc4 in start_thread (arg=0x761ff2b0) at pthread_create.c:458 #17 0x76de2038 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76 from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 4 (Thread 0x757ff2b0 (LWP 7632)): #0 0x76ce19a4 in __pthread_cond_wait (cond=0x7520f000, mutex=0x75215030) at pthread_cond_wait.c:188 #1 0x00920f4c in futures::task_impl::std::ThreadNotify::park::h7b4e63dd494d5597 () #2 0x0056c98c in _$LT$std..thread..local..LocalKey$LT$T$GT$$GT$::with::hf6072a215a39b3b8 () #3 0x00566570 in futures::future::Future::wait::h8064970af9245539 () #4 0x0055c678 in librespot_playback::player::PlayerInternal::run::hedda082537cecf78 () #5 0x004fb12c in std::sys_common::backtrace::__rust_begin_short_backtrace::hb57c86e1fbda9cc9 () #6 0x004e9150 in std::panicking::try::do_call::hd65e9edeebabae0e () #7 0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105 #8 0x004fd578 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h3a3c2b783a091036 () #9 0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT $A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648 #10 std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24 #11 0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90 #12 0x76cdafc4 in start_thread (arg=0x757ff2b0) at pthread_create.c:458 #13 0x76de2038 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76 from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 5 (Thread 0x74dff2b0 (LWP 26956)): #0 0x76ce19a4 in __pthread_cond_wait (cond=0x7681e5d0, mutex=0x76948ea0) at pthread_cond_wait.c:188 #1 0x009a75c4 in std::sys::unix::condvar::Condvar::wait::hab93781440f55022 () at libstd/sys/unix/condvar.rs:78 #2 std::sys_common::condvar::Condvar::wait::hda28562b419be3ea () at libstd/sys_common/condvar.rs:51 #3 std::sync::condvar::Condvar::wait::ha0917b1f460848fe () at libstd/sync/condvar.rs:214 ---Type <return> to continue, or q <return> to quit--- #4 std::thread::park::h93884c2ad9e85a2d () at libstd/thread/mod.rs:803 #5 0x009b034c in std::sync::mpsc::blocking::WaitToken::wait::hb4820b1cfd0e3ab9 () at libstd/sync/mpsc/blocking.rs:81 #6 0x00919fec in _$LT$std..sync..mpsc..oneshot..Packet$LT$T$GT$$GT$::recv::h10911dd8ed02a40b () #7 0x00911e1c in _$LT$std..sync..mpsc..Receiver$LT$T$GT$$GT$::recv::h86a65277c2302820 () #8 0x0090f83c in futures_cpupool::Inner::work::hc3d513a7f0b1bfdb () #9 0x00910c88 in std::sys_common::backtrace::__rust_begin_short_backtrace::h41985cfd798e9ad4 () #10 0x009114e0 in std::panicking::try::do_call::h954acf9a59e0fa2f () #11 0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105 #12 0x009112d0 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h1a23aeeec05d132e () #13 0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT $A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648 #14 std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24 #15 0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90 #16 0x76cdafc4 in start_thread (arg=0x74dff2b0) at pthread_create.c:458 Backtrace stopped: Cannot access memory at address 0x14 Thread 6 (Thread 0x75dfd2b0 (LWP 26957)): #0 0x76ce4f40 in __lll_lock_wait (futex=futex@entry=0x76948e88, private=0) at lowlevellock.c:43 #1 0x76cddbd4 in __GI___pthread_mutex_lock (mutex=0x76948e88) at pthread_mutex_lock.c:80 #2 0x0090f814 in futures_cpupool::Inner::work::hc3d513a7f0b1bfdb () #3 0x00910c88 in std::sys_common::backtrace::__rust_begin_short_backtrace::h41985cfd798e9ad4 () #4 0x009114e0 in std::panicking::try::do_call::h954acf9a59e0fa2f () #5 0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105 #6 0x009112d0 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h1a23aeeec05d132e () #7 0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT $A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648 #8 std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24 #9 0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90 #10 0x76cdafc4 in start_thread (arg=0x75dfd2b0) at pthread_create.c:458 Backtrace stopped: Cannot access memory at address 0x14 Thread 7 (Thread 0x75ffe2b0 (LWP 26958)): #0 0x76ce4f40 in __lll_lock_wait (futex=futex@entry=0x76948e88, private=0) at lowlevellock.c:43 #1 0x76cddbd4 in __GI___pthread_mutex_lock (mutex=0x76948e88) at pthread_mutex_lock.c:80 #2 0x0090f814 in futures_cpupool::Inner::work::hc3d513a7f0b1bfdb () #3 0x00910c88 in std::sys_common::backtrace::__rust_begin_short_backtrace::h41985cfd798e9ad4 () #4 0x009114e0 in std::panicking::try::do_call::h954acf9a59e0fa2f () #5 0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105 #6 0x009112d0 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h1a23aeeec05d132e () #7 0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT $A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648 #8 std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24 #9 0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90 #10 0x76cdafc4 in start_thread (arg=0x75ffe2b0) at pthread_create.c:458 Backtrace stopped: Cannot access memory at address 0x14 Thread 8 (Thread 0x747ff2b0 (LWP 26959)): #0 0x76ce4f40 in __lll_lock_wait (futex=futex@entry=0x76948e88, private=0) at lowlevellock.c:43 #1 0x76cddbd4 in __GI___pthread_mutex_lock (mutex=0x76948e88) at pthread_mutex_lock.c:80 #2 0x0090f814 in futures_cpupool::Inner::work::hc3d513a7f0b1bfdb () #3 0x00910c88 in std::sys_common::backtrace::__rust_begin_short_backtrace::h41985cfd798e9ad4 () #4 0x009114e0 in std::panicking::try::do_call::h954acf9a59e0fa2f () #5 0x009baaac in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105 #6 0x009112d0 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h1a23aeeec05d132e () #7 0x009adeac in _$LT$alloc..boxed..Box$LT$alloc..boxed..FnBox$LT$A$C$$u20$Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT $A$GT$$GT$::call_once::hb9e8d47ffc984c2e () at /checkout/src/liballoc/boxed.rs:648 #8 std::sys_common::thread::start_thread::hf9e3e04939d5f0be () at libstd/sys_common/thread.rs:24 #9 0x009b0b28 in std::sys::unix::thread::Thread::new::thread_start::hb5f20e9ac9231edc () at libstd/sys/unix/thread.rs:90 #10 0x76cdafc4 in start_thread (arg=0x747ff2b0) at pthread_create.c:458 Backtrace stopped: Cannot access memory at address 0x14 (gdb) info threads Id Target Id Frame * 1 Thread 0x76f92340 (LWP 918) "librespot" 0x76cdc464 in pthread_join (threadid=<optimized out>, thread_return=0x0) at pthread_join.c:90 2 Thread 0x767ff2b0 (LWP 926) "librespot" 0x76de2704 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84 3 Thread 0x761ff2b0 (LWP 6252) "librespot" 0x76ce19a4 in __pthread_cond_wait (cond=0x7681e390, mutex=0x7681b798) at pthread_cond_wait.c:188 4 Thread 0x757ff2b0 (LWP 7632) "librespot" 0x76ce19a4 in __pthread_cond_wait (cond=0x7520f000, mutex=0x75215030) at pthread_cond_wait.c:188 5 Thread 0x74dff2b0 (LWP 26956) "hyper-dns0" 0x76ce19a4 in __pthread_cond_wait (cond=0x7681e5d0, mutex=0x76948ea0) at pthread_cond_wait.c:188 6 Thread 0x75dfd2b0 (LWP 26957) "hyper-dns1" 0x76ce4f40 in __lll_lock_wait (futex=futex@entry=0x76948e88, private=0) at lowlevellock.c:43 7 Thread 0x75ffe2b0 (LWP 26958) "hyper-dns2" 0x76ce4f40 in __lll_lock_wait (futex=futex@entry=0x76948e88, private=0) at lowlevellock.c:43 8 Thread 0x747ff2b0 (LWP 26959) "hyper-dns3" 0x76ce4f40 in __lll_lock_wait (futex=futex@entry=0x76948e88, private=0) at lowlevellock.c:43 ``` I made a core dump file. If it helps, I can share it (but I'm a bit hesitant, since I'm not sure if there's sensitive credentials in there).

kerem 2026-02-27 19:29:33 +03:00

• closed this issue
• added the
  bug
  duplicate
  labels

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@matthijskooijman commented on GitHub (Jul 23, 2019):

I tried to dig into this a bit further, and it turns out the coredump might not be so useful after all. It seems that gdb does not know (or fails to read) the list of shared libraries loaded at runtime, which means it fails to load the debugging symbols of the libraries in use, and fails to render the backtrace. I also noticed that the "program entry point" (as printed by "info shared" IIRC) was different between a running process and a core dump, which might also be related. It also seems that rust has a fairly complicated multithreading model, so I haven't figured out any extra info from debugging a locked up process directly...

<!-- gh-comment-id:514189790 --> @matthijskooijman commented on GitHub (Jul 23, 2019): I tried to dig into this a bit further, and it turns out the coredump might not be so useful after all. It seems that gdb does not know (or fails to read) the list of shared libraries loaded at runtime, which means it fails to load the debugging symbols of the libraries in use, and fails to render the backtrace. I also noticed that the "program entry point" (as printed by "info shared" IIRC) was different between a running process and a core dump, which might also be related. It also seems that rust has a fairly complicated multithreading model, so I haven't figured out any extra info from debugging a locked up process directly...

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@PMaynard commented on GitHub (Nov 28, 2019):

I am also experiencing this issue. After 1-3 songs (via Spotifyd 0.2.20) I get the error Connection reset by peer, so I enabled verbose logging (Full debug log can be found here )

11:55:22 [ERROR] Caught panic with message: Spotify servers returned an error. Restart librespot.

Going to try with a fresh compile. Will update with results.

EDIT: Error still happens with a fresh build

<!-- gh-comment-id:559447468 --> @PMaynard commented on GitHub (Nov 28, 2019): I am also experiencing this issue. After 1-3 songs (via Spotifyd 0.2.20) I get the error `Connection reset by peer`, so I enabled verbose logging (Full debug log can be found [here](https://pastebin.com/rRYRSL2b) ) > 11:55:22 [ERROR] Caught panic with message: Spotify servers returned an error. Restart librespot. Going to try with a fresh compile. Will update with results. EDIT: Error still happens with a fresh build

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@espindola commented on GitHub (Apr 29, 2020):

I was having the ConnectionReset problem. What seems to have solved it making sure pulseaudio never quits. Instead of running it with systemd, what I did was

Disable pulseaudio.socket:
$ sudo systemctl --global disable pulseaudio.service pulseaudio.socket

On daemon.conf, disable exit on idle:
exit-idle-time = -1

In default.pa, comment
load-module module-systemd-login

With that I have librespot running on a raspberrypi for a day and no problems so far.

<!-- gh-comment-id:621236981 --> @espindola commented on GitHub (Apr 29, 2020): I was having the ConnectionReset problem. What seems to have solved it making sure pulseaudio never quits. Instead of running it with systemd, what I did was Disable pulseaudio.socket: $ sudo systemctl --global disable pulseaudio.service pulseaudio.socket On daemon.conf, disable exit on idle: exit-idle-time = -1 In default.pa, comment load-module module-systemd-login With that I have librespot running on a raspberrypi for a day and no problems so far.

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@idofr commented on GitHub (May 21, 2020):

@espindola a bit of a dull question, but are you using alsa or pulseaudio as your backend?
I'm having the same problem with spotifyd but it's using alsa as a backend

<!-- gh-comment-id:632014413 --> @idofr commented on GitHub (May 21, 2020): @espindola a bit of a dull question, but are you using alsa or pulseaudio as your backend? I'm having the same problem with `spotifyd` but it's using alsa as a backend

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@espindola commented on GitHub (May 21, 2020):

@espindola a bit of a dull question, but are you using alsa or pulseaudio as your backend?
I'm having the same problem with spotifyd but it's using alsa as a backend

I am using pulseaudio

<!-- gh-comment-id:632163511 --> @espindola commented on GitHub (May 21, 2020): > @espindola a bit of a dull question, but are you using alsa or pulseaudio as your backend? > I'm having the same problem with `spotifyd` but it's using alsa as a backend I am using pulseaudio

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@dangerfish96 commented on GitHub (Jun 17, 2020):

I am not quite sure whether this is the same issue but librespot stops to work after about 3 songs aswell, with the log:

[2020-06-17T13:13:09Z ERROR librespot_core::session] Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }                                
[2020-06-17T13:13:09Z WARN  librespot] Spirc shut down unexpectedly                                                                                              
[2020-06-17T13:13:09Z WARN  librespot_audio::fetch] Error from channel for data receiver for range 8216576 (+16384).      

<!-- gh-comment-id:645371641 --> @dangerfish96 commented on GitHub (Jun 17, 2020): I am not quite sure whether this is the same issue but librespot stops to work after about 3 songs aswell, with the log: ``` [2020-06-17T13:13:09Z ERROR librespot_core::session] Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" } [2020-06-17T13:13:09Z WARN librespot] Spirc shut down unexpectedly [2020-06-17T13:13:09Z WARN librespot_audio::fetch] Error from channel for data receiver for range 8216576 (+16384). ```

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@utkiupe commented on GitHub (Aug 21, 2020):

Hi, I am using Librespot through raspotify, experiencing recently many playback stops after a while (seems very random to me sometime after a couple of minutes, sometime after a longer time).
My logs look similar to those reported earlier :

Aug 21 10:11:09 pibureau librespot[27145]: [2020-08-21T08:11:09Z ERROR librespot_playback::player] Unable to load audio item.
Aug 21 10:11:09 pibureau librespot[27145]: [2020-08-21T08:11:09Z ERROR librespot_core::session] Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
Aug 21 10:11:09 pibureau librespot[27145]: [2020-08-21T08:11:09Z WARN  librespot] Spirc shut down unexpectedly
Aug 21 10:11:10 pibureau librespot[27145]: [2020-08-21T08:11:10Z INFO  librespot_core::session] Connecting to AP "gew1-accesspoint-b-rx4r.ap.spotify.com:4070"
Aug 21 10:11:10 pibureau librespot[27145]: [2020-08-21T08:11:10Z INFO  librespot_core::session] Authenticated as "XXXXXXXXX" !
Aug 21 10:11:10 pibureau librespot[27145]: [2020-08-21T08:11:10Z INFO  librespot_playback::audio_backend::alsa] Using alsa sink
Aug 21 10:11:10 pibureau librespot[27145]: [2020-08-21T08:11:10Z INFO  librespot_core::session] Country: "FR"

I have also noticed that before this I have a dozen of

Aug 21 10:23:04 pibureau librespot[27145]: [2020-08-21T08:23:04Z WARN  libmdns::fsm] dropping truncated packet from V6([2a01:cb14:b84:4500]:5353)
Aug 21 10:23:04 pibureau librespot[27145]: [2020-08-21T08:23:04Z WARN  libmdns::fsm] dropping truncated packet from V4(192.168.0.254:5353)

any ideas on how to fix that? Is it something related to our configuration ?

thanks

<!-- gh-comment-id:678114571 --> @utkiupe commented on GitHub (Aug 21, 2020): Hi, I am using Librespot through raspotify, experiencing recently many playback stops after a while (seems very random to me sometime after a couple of minutes, sometime after a longer time). My logs look similar to those reported earlier : ``` Aug 21 10:11:09 pibureau librespot[27145]: [2020-08-21T08:11:09Z ERROR librespot_playback::player] Unable to load audio item. Aug 21 10:11:09 pibureau librespot[27145]: [2020-08-21T08:11:09Z ERROR librespot_core::session] Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" } Aug 21 10:11:09 pibureau librespot[27145]: [2020-08-21T08:11:09Z WARN librespot] Spirc shut down unexpectedly Aug 21 10:11:10 pibureau librespot[27145]: [2020-08-21T08:11:10Z INFO librespot_core::session] Connecting to AP "gew1-accesspoint-b-rx4r.ap.spotify.com:4070" Aug 21 10:11:10 pibureau librespot[27145]: [2020-08-21T08:11:10Z INFO librespot_core::session] Authenticated as "XXXXXXXXX" ! Aug 21 10:11:10 pibureau librespot[27145]: [2020-08-21T08:11:10Z INFO librespot_playback::audio_backend::alsa] Using alsa sink Aug 21 10:11:10 pibureau librespot[27145]: [2020-08-21T08:11:10Z INFO librespot_core::session] Country: "FR" ``` I have also noticed that before this I have a dozen of ``` Aug 21 10:23:04 pibureau librespot[27145]: [2020-08-21T08:23:04Z WARN libmdns::fsm] dropping truncated packet from V6([2a01:cb14:b84:4500]:5353) Aug 21 10:23:04 pibureau librespot[27145]: [2020-08-21T08:23:04Z WARN libmdns::fsm] dropping truncated packet from V4(192.168.0.254:5353) ``` any ideas on how to fix that? Is it something related to our configuration ? thanks

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@all3kcis commented on GitHub (Oct 1, 2020):

Same here, it looks like #331.

<!-- gh-comment-id:702168672 --> @all3kcis commented on GitHub (Oct 1, 2020): Same here, it looks like #331.

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@paulbastian commented on GitHub (Nov 22, 2020):

same problem for me

<!-- gh-comment-id:731745191 --> @paulbastian commented on GitHub (Nov 22, 2020): same problem for me

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@mutipg commented on GitHub (Nov 25, 2020):

Same issue on new Raspberry Pi 4. After 2 songs raspotify disconnects with errors:

Nov 25 23:36:34 raspberrypi librespot[22993]: [2020-11-25T22:36:34Z INFO  librespot_playback::player] Loading <Caution - Radio Edit> with Spotify URI <spotify:track:4cI2rd2D44mBjwUVFxTkUZ>
Nov 25 23:36:34 raspberrypi librespot[22993]: [2020-11-25T22:36:34Z INFO  librespot_playback::player] <Caution - Radio Edit> (228040 ms) loaded
Nov 25 23:39:14 raspberrypi librespot[22993]: [2020-11-25T22:39:14Z ERROR librespot_playback::player] Unable to load audio item.
Nov 25 23:39:14 raspberrypi librespot[22993]: [2020-11-25T22:39:14Z ERROR librespot_core::session] Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
Nov 25 23:39:14 raspberrypi librespot[22993]: [2020-11-25T22:39:14Z WARN  librespot] Spirc shut down unexpectedly

<!-- gh-comment-id:733979201 --> @mutipg commented on GitHub (Nov 25, 2020): Same issue on new Raspberry Pi 4. After 2 songs raspotify disconnects with errors: ``` Nov 25 23:36:34 raspberrypi librespot[22993]: [2020-11-25T22:36:34Z INFO librespot_playback::player] Loading <Caution - Radio Edit> with Spotify URI <spotify:track:4cI2rd2D44mBjwUVFxTkUZ> Nov 25 23:36:34 raspberrypi librespot[22993]: [2020-11-25T22:36:34Z INFO librespot_playback::player] <Caution - Radio Edit> (228040 ms) loaded Nov 25 23:39:14 raspberrypi librespot[22993]: [2020-11-25T22:39:14Z ERROR librespot_playback::player] Unable to load audio item. Nov 25 23:39:14 raspberrypi librespot[22993]: [2020-11-25T22:39:14Z ERROR librespot_core::session] Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" } Nov 25 23:39:14 raspberrypi librespot[22993]: [2020-11-25T22:39:14Z WARN librespot] Spirc shut down unexpectedly ```

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@paulbastian commented on GitHub (Nov 26, 2020):

Although I don't like running java on a headless raspberry pi, I want to state, that the librespot-java project works flawless and I'm not getting any disconnects there

<!-- gh-comment-id:734371389 --> @paulbastian commented on GitHub (Nov 26, 2020): Although I don't like running java on a headless raspberry pi, I want to state, that the librespot-java project works flawless and I'm not getting any disconnects there

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@mutipg commented on GitHub (Nov 26, 2020):

@paulbastian, thank you for your suggestion!

For about one hour Spotify plays without disconnects. So Spocon based on librespot-java is quite good alternative for Raspotify.

<!-- gh-comment-id:734453741 --> @mutipg commented on GitHub (Nov 26, 2020): @paulbastian, thank you for your suggestion! For about one hour Spotify plays without disconnects. So Spocon based on librespot-java is quite good alternative for Raspotify.

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@Malvineous commented on GitHub (Feb 23, 2021):

The "Connection reset by peer" error is because the Spotify network connection broke, for reasons like a Spotify server was shut down, your Internet connection went offline briefly, or many other issues. librespot should try to automatically reconnect in this case but it doesn't always seem to for some reason.

<!-- gh-comment-id:784104712 --> @Malvineous commented on GitHub (Feb 23, 2021): The "Connection reset by peer" error is because the Spotify network connection broke, for reasons like a Spotify server was shut down, your Internet connection went offline briefly, or many other issues. librespot should try to automatically reconnect in this case but it doesn't always seem to for some reason.

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@utkiupe commented on GitHub (Feb 23, 2021):

this is probably the reason we need to investigate :)
I guess all the Spotify clients face the same kind of issue and have found some workaround.
I am not able to help you for coding but I'll be more than happy to help you as much as I could

<!-- gh-comment-id:784113653 --> @utkiupe commented on GitHub (Feb 23, 2021): this is probably the reason we need to investigate :) I guess all the Spotify clients face the same kind of issue and have found some workaround. I am not able to help you for coding but I'll be more than happy to help you as much as I could

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@roderickvd commented on GitHub (May 24, 2021):

Is this still happening for you?

It's known that reconnection isn't handled well. This is likely to be fixed when we get the new API in, which supports reconnection from the ground up.

With the current librespot version however (assuming a stable network) I have no issues running librespot heedlessly for days and weeks at end, connecting and disconnecting in the evenings.

<!-- gh-comment-id:847350545 --> @roderickvd commented on GitHub (May 24, 2021): Is this still happening for you? It's known that reconnection isn't handled well. This is likely to be fixed when we get the new API in, which supports reconnection from the ground up. With the current `librespot` version however (assuming a stable network) I have no issues running `librespot` heedlessly for days and weeks at end, connecting and disconnecting in the evenings.

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@espindola commented on GitHub (May 24, 2021):

I haven't noticed this issue in a long time. Not sure what changed.

<!-- gh-comment-id:847373322 --> @espindola commented on GitHub (May 24, 2021): I haven't noticed this issue in a long time. Not sure what changed.

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@Malvineous commented on GitHub (May 25, 2021):

I still see it maybe once a week? Often it will reconnect without any issues but occasionally it just crashes completely. It is rare enough that it isn't causing me any problems but it is still happening.

<!-- gh-comment-id:847466225 --> @Malvineous commented on GitHub (May 25, 2021): I still see it maybe once a week? Often it will reconnect without any issues but occasionally it just crashes completely. It is rare enough that it isn't causing me any problems but it is still happening.

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@roderickvd commented on GitHub (May 25, 2021):

Which version are you on?

<!-- gh-comment-id:847578837 --> @roderickvd commented on GitHub (May 25, 2021): Which version are you on?

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@Malvineous commented on GitHub (May 25, 2021):

I haven't upgraded in a while as it has been running without issue. But I leave it connected 24/7 so that's probably why. I guess if you disconnect and reconnect you probably won't see it if it's due to Spotify rebooting servers from time to time.

<!-- gh-comment-id:847588856 --> @Malvineous commented on GitHub (May 25, 2021): I haven't upgraded in a while as it has been running without issue. But I leave it connected 24/7 so that's probably why. I guess if you disconnect and reconnect you probably won't see it if it's due to Spotify rebooting servers from time to time.

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@roderickvd commented on GitHub (May 25, 2021):

Please try the latest and report back. There's been a rather large upgrade and rewrite of the asynchronous functions. I also see in main that there will be up to five reconnection attempts when spirc shuts down unexpectedly.

It's probably a lot better than it was, and it's about as good as it's going to get until the new API gets in.

<!-- gh-comment-id:848206709 --> @roderickvd commented on GitHub (May 25, 2021): Please try the latest and report back. There's been a rather large upgrade and rewrite of the asynchronous functions. I also see in `main` that there will be up to five reconnection attempts when `spirc` shuts down unexpectedly. It's probably a lot better than it was, and it's about as good as it's going to get until the new API gets in.

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@roderickvd commented on GitHub (Jun 14, 2021):

Duplicate of #276.

<!-- gh-comment-id:860575427 --> @roderickvd commented on GitHub (Jun 14, 2021): Duplicate of #276.

kerem commented 2026-02-27 19:29:34 +03:00

Author

Owner

Copy link

@Malvineous commented on GitHub (Sep 2, 2021):

Sorry for the late reply. Been running the updated code for the last two months and it does seem to be a lot more reliable. It will automatically reconnect but it won't resume the previously playing track which somewhat defeats the point as I still have to go mess with it to get it playing again, but it's definitely a step in the right direction!

<!-- gh-comment-id:911324659 --> @Malvineous commented on GitHub (Sep 2, 2021): Sorry for the late reply. Been running the updated code for the last two months and it does seem to be a lot more reliable. It will automatically reconnect but it won't resume the previously playing track which somewhat defeats the point as I still have to go mess with it to get it playing again, but it's definitely a step in the right direction!

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

dev

v0.8.0

v0.7.1

v0.7.0

v0.6.0

v0.5.0

v0.4.2

v0.4.1

v0.4.0

v0.3.1

v0.3.0

v0.2.0

v0.1.6

v0.1.5

v0.1.3

v0.1.2

v0.1.1

v0.1.0

Labels

Clear labels   

A-Alsa

  

SpotifyAPI

  

Tokio 1.0

  

audio

  

bug

  

can't reproduce

  

compilation

  

dependencies

  

duplicate

  

enhancement

  

good first issue

  

help wanted

  

high priority

  

imported

  

imported

  

invalid

  

new api

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

reverse engineering

  

wiki

  

wontfix

No labels

A-Alsa

SpotifyAPI

Tokio 1.0

audio

bug

can't reproduce

compilation

dependencies

duplicate

enhancement

good first issue

help wanted

high priority

imported

imported

invalid

new api

pull-request

question

reverse engineering

wiki

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#233

No description provided.