Spot loses connection and stops playing

[ghost]

On a pretty stable network, Spot suddenly stops playing and refuses to play again until I quit the app altogether. When I do quit though, it requests me to enter my login credentials again. This happens pretty often.

Now, I don't know how to generate a bug report; I am new to Linux and not very tech savvy in general but if there's anything I can do, I gladly will (if you guide me).

I installed Spot on Elementary OS from Flathub.

[xou816]

Hi there thanks for the report! Is there a way to install Seahorse or GNOME Keyring? This might help with your issues.

But you're right, it's worth investigating why the session is not kept alive without gnome keyring, that sounds like a regression :/

[iam-cult]

Have this issue as well, Fedora Silverblue 35

[Pinjontall94]

I seem to be getting the same error with Gnome keyring. I am using automatic login, though. OS: Ubuntu 21.04

EDIT: After reentering credentials to Spot, I notice I get the "Could not save password. Make sure keyring is unlocked." message. As far as I know my keyring is unlocked, but maybe autologin messes with that?

[xou816]

I havent been able to reproduce it with the keyring locked today so nevermind that it is something else :/

[iam-cult]

I havent been able to reproduce it with the keyring locked today so nevermind that it is something else :/

Only happens after long periods of suspension for me. I wake up the computer, and then I try to play something and nothing plays, and then I restart spot and it prompts me for my login.

[tatiee]

Chiming in here - I've been hitting my head against the wall about connection issues and found running spot via terminal fixes it. Not sure if it'll help anyone else but it's a nice workaround to try.

Never mind - just crashed after 4/5 songs

(spot:2): Gtk-WARNING **: 17:33:33.536: GtkListView failed to scroll to given position. Ignoring... thread '' panicked at 'failed to spawn thread: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }', /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/thread/mod.rs:622:29 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace thread 'async-std/runtime' panicked at 'called Result::unwrap() on an Err value: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }', /run/build/spot/cargo/vendor/blocking-1.0.2/src/lib.rs:210:18 thread 'async-std/runtimethread 'main' panicked at 'task has failed', ' panicked at '/run/build/spot/cargo/vendor/async-task-4.0.3/src/task.rscalled Result::unwrap() on an Err value: PoisonError { .. }:', 368/run/build/spot/cargo/vendor/blocking-1.0.2/src/lib.rs::45182: 43

(spot:2): GdkPixbuf-WARNING **: 17:46:49.169: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. You must explicitly end the data stream to the loader before dropping the last reference.

[nmschulte]

I think I'm experiencing an issue similar to this, related to an unstable (cellular) Internet connection.

My device will stop playing audio from Spot, though Spot will seemingly continue to function allowing changing songs from my album, play/pause etc. The only way to make it work again is to pause the playback, exit Spot, typically then bounce the cellular modem and wait for a connection, restart Spot, and find the album/song and play again. This occurs very frequently while driving about; I'm lucky if I can get through a single track before this occurs again.

Additionally, likely related, when a song ends and the next begins, Spot will seem to incur this issue; basically 100% of the time while driving and a new song comes up, this occurs. While stationary, presumably because I'm not switching cellular towers, this rarely if ever occurs.

Sometimes, however, if I'm patient enough, Spot will seem to understand the situation and stop playback, at which point I can ensure a stable Internet connection and simply start playback again without closing Spot (and sometimes even without bouncing the cellular modem).

As well, if I'm using a Bluetooth sink, when this happens (Spot seems like it's playing but no audio is output; likely related/due to a spotty (:laughing:) Internet connection), I can stop playback, bounce the Bluetooth connection, and restart playback, without having to bounce Spot.

Looking at the pulseaudio logs, it seems like when this occurs, the pulseaudio stream/... times out, and the only way to re-initialize it is to restart Spot, or e.g. poke pulseaudio in a way that changes the configured audio sink.

This all leads me to believe there's some bug w/re: Spotify connection and how Spot conveys this to the user and how Spot manages it's pulseaudio objects.

I'll keep investigating, as Spot is the nicest graphical client I've found so far for my mobile (64-bit ARM) device.