Spotifyd/spotifyd

Cannot resume playing after a few hours of being idle (Couldn't fetch metadata from spotify: Nothing playing at the moment)

Galicarnax opened this issue · 2 comments

Description

NOTE: this is probably not a duplicate of #706, as I still can see spotifyd in the list of connected devices in spt and official apps.

Having spotifyd installed on RPi4 (Arch Linux ARM). Playback is controlled from another host with playerctl. Works fine if spotifyd is in use for some time. After pausing and leaving for a few hours, I cannot resume play with playerctl. Looking at spotifyd logs, I see this when I ask to resume playing:

Couldn't fetch metadata from spotify: Nothing playing at the moment

I have to go to spt or official app to connect to spotifyd again and only then it can resume from the point where I left.

Probably this has something to do with spotify's API token timeout or smth like that, as in the logs I see the following after some time I paused and left, and before I tried to resume:

Jan 07 12:33:13 raspi spotifyd[1791785]: subscription terminated
Jan 07 12:33:13 raspi spotifyd[1791785]: Connecting to AP "ap.spotify.com:443"
Jan 07 12:33:13 raspi spotifyd[1791785]: Connection reset by peer (os error 104)
Jan 07 12:33:15 raspi spotifyd[1791785]: Authenticated as "..." !
Jan 07 12:33:15 raspi spotifyd[1791785]: Country: "..."

Still, spotifyd successfully reconnects and becomes visible in connected devices. So why can't it just resume playing?

To Reproduce

  1. Launch spotifyd
  2. Connect from spt and start playing
  3. Pause with playerctl
  4. Leave for few hours
  5. Resume with playerctl to no avail

Expected behavior

Should just resume playing.

Compilation flags

  • dbus_mpris
  • dbus_keyring
  • alsa_backend
  • portaudio_backend
  • pulseaudio_backend
  • rodio_backend

Versions (please complete the following information):

  • OS: Arch Linux ARM (aarch64)
  • Spotifyd: 0.3.4
  • cargo: 1.66.0

it seems actually very related / potential duplicate of this issue #1155. only difference seems that playerctl might trigger a different sequence of API commands. can you provide the exact playerctl command for the record please (or maybe even better the direct dbus mpris command)

but the additional problem you are facing is actually that you are experiencing this reconnect. it is very likely triggered by an unstable internet connection (temp. packet loss, low ping) or a buggy firmware of the modem/router/firewall. once i had a technician fixing my cable internet profile on the provider side i can resume music after hours and days using the spotify API with spotifyd 0.3.4. no reconnect is happening for me anymore.

reconnecting seems to have the same effect like restarting spotifyd. spotifyd forgets its playback context in both cases. a feature to restore that as I described in #1155 should also resolve your issue.

Thank you @JJ-Author for linking that issue. The issue here is indeed that after spotifyd reconnects, it is no longer the active playback device (or even authenticated when using discovery) and as such can't really resume by itself (at least in the current state). The error that you're seeing is actually coming from playerctl trying to request some metadata from spotifyd, which internally calls the Web API and doesn't find anything to return.

I'm going to close this, since there is #1155 and #706. (I think, the latter is actually kind of the same issue with the difference that spotifyd now supports reconnecting – at least more than at that time.) However, feel free to ping me, if you disagree, or I misunderstood the problem!