Device disappears after being idle for some hours

[Semmu]

Description
Hi,

I have recently bought a new router (TP-Link Archer AX1800) and since then spotifyd always disappears from my Spotify Connect devices list after some hours of being idle (e.g. I leave my home).
This is always happening, though the timeout does seem to vary a bit.

Because it happens since the introduction of my new router, I suspect some networking issue, like some TCP connection being closed despite still in use, even if barely.

Unfortunately spotifyd does not realize its connection has been closed and does not restart automatically (which would solve the problem), nothing interesting is printed in the logs, so I always have to restart the service manually, which is pretty annoying.

Could you please implement some heartbeat check or more pedantic network connection handling, so maybe it can detect connection issues and reconnect if needed?

Thanks in advance!

To Reproduce
0. (buy and use TP-Link Archer AX1800)

1. Start spotifyd, play some music
2. Stop playing music, but keep spotifyd running
3. Leave spotifyd alone for some hours
4. Notice that spotifyd is not in the Spotify Connect devices list anymore 😞

Expected behavior
4. Notice that spotifyd is still in the Spotify Connect devices list 😊

Logs

Click to show logs

Nothing special in the logs, but I did not run it with --verbose. Made the change now, and will include the logs here when I encounter the issue next time.

Compilation flags

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

(Downloaded the binary release from here.)

Versions (please complete the following information):

• OS: Ubuntu 18.04.5 LTS bionic (Linux 4.14.180-178 Add Upstart job (not installed with make) #1 SMP PREEMPT Wed Sep 2 12:39:45 -03 2020 armv7l armv7l armv7l GNU/Linux)
• Spotifyd: spotifyd 0.3.0
• cargo: not installed

[Semmu]

It happened again and there is nothing related found in the logs, even with verbose logging enabled.

Screenshot of evidence: spotifyd running without issues, but it does not show up in the devices list.

[robinvd]

Thanks for the bug report! i have not seen this before. Could you try to run https://github.com/librespot-org/librespot on its own and see if it still happens, its the depency we use for the spotify connection.

[Semmu]

good point, i will try that

[vhristev]

I experience the same issue on OSX 11.2.3 (20D91) and spotifyd 0.3.2 .

Im using https://github.com/Rigellute/spotify-tui to connect.
I found out that my MacSound device disappear after idle. As @Semmu said there are no logs im trying to find the root cause. Laptop is always connected to Ethernet ( don't use WIFI ).

[friedemannm]

I have exactly the same problem on raspberry pi 3 with wifi connection

[shiraneyo]

I'm also experiencing the exact same issue on my Raspberry Pi 3 that runs ArchLinux with spotifyd v0.3.2. I suspect this might be related to #706.

Is there any way to add a healtcheck to the spotifyd daemon, to make it query the list of devices on the Spotify API and re-register itself if it's missing from there?
Otherwise a workaround would be a script that performs that check, and marks the spotifyd system service as 'stopped' to force a restart.

[emanuelserpa]

Same problem here, trying to use spotifyd as my main client and if I stop using it for some hours spotifyd just disappears and stop responding. The spotifyd process keeps running as a zombie.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cauebs]

This bot is so problematic... The issue is still relevant.

[vhristev]

The issue is still relevant I still need to restart the spotifyd before i use 'spt' otherwise i dont have my Mac as output device.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[emanuelserpa]

Issue still relevant

[eladyn]

Has anyone ever tried this proposal to track down, what causes this problem?

[BlackYps]

I guess I first need to install plain librespot for this, right? I haven't really figured out the relation between spotifyd and librespot

[eladyn]

Yeah, you can have a look at their README on how to do this.

As far as I know, librespot provides several things: It can be used as a library, to build a custom spotify client, which is done by e.g. spotifyd, ncspot, spot and many others. Alternatively, it can be installed as a binary and as such be used as a standalone client. This is something that is done by e.g. raspotify or when you install it directly via cargo install.

So in this case, trying librespot in its standalone version can show, wether the problem lies the way spotifyd uses librespot or if librespot itself has the bug in its upstream version as well.

[BlackYps]

I found out that my Pi Zero 2 W can't handle building the rust packages. I tried to do it on my PC instead, but obviously I have to cross-compile, because the Pi uses arm architecture. I already spent a lot of time now, I am no closer to a solution and it is obvious that it will have to spend a lot more time to understand rust compilation. At this point it seems more reasonable for me to try my luck with raspotify and see if the issue also happens there.
For the issue with spotifyd here I am afraid I can't contribute any more, sadly.

[eladyn]

Sure, no worries. Thanks for trying!

But if it works for you with raspotify that would still be valuable information, since raspotify just executes the librespot binary and wraps it into a debian package, IIRC. So running it successfully would then mean that at least the newest librespot does not suffer from the problem.

[BlackYps]

good news, I discovered that when you install raspotify you can also use librespot directly. I will report back when I have tested it for a while to see if the original bug described here surfaces again

[BlackYps]

I can confirm that it still happens when using plain librespot. I also found a related issue: librespot-org/librespot#247
Note that the issue itself is closed because the underlying issue is discussed here: librespot-org/librespot#609

[Quest24]

I have the same problem, but only on 1 of 3 devices. I run spotifd version 0.3.3 . I have used raspotify, which uses librespot, for a few years. In June 2022 with the new version of spotify, the API broke, so I switched to spotfifyd with success. I have 3 raspberry pi's running this software. 2 are running ok, but one device will disapear after somte time in spotify when nothing is played. This pi is behind an extra switch. With raspotify I had exactly the same behaviour. After restarting spotifyd on this pi, everything works ok for a while. The other two pi's never have this problem.

[AberDerBart]

I have the same issue on a Raspberry Pi 4, running ppotifyd 3.3.0 on nixos connected to a Fritzbox 7362 SL via wifi.

[Semmu]

I actually managed to solve this problem indirectly by turning off a lot of "advanced" features in my router a long time ago. I guess those settings somehow caused spotifyd to disconnect. Unfortunately I don't remember the exact features I turned off, because I didn't think it will have any effect on this issue.

But I recommend playing around in your router settings if you have the option.

@Quest24 's answer also seems to support this theory as he has an extra switch in front of the problematic spotifyd, so I guess his problem is the same.

[Semmu]

Well, it started disappearing for me very frequently again, since a week or so... And I didn't change a thing, not in my network, nor did I upgrade my spotifyd version. So I suspect something has been changed on the other side of the equation, I think the devs did something at Spotify.

Does any of you experience a sudden increase of spotifyd disappearing?

[pwall2222]

Well for one Spotify changed it's sdk recently so maybe there are some issues with that.

[Quest24]

I tried it yesterday, but the problem is stil there. After one day, one device will disappear from the list. After restarting it becomes visibable again. Everything will work as long as a play music on that device, but wil disappear after stop playing.

[allys7]

I experienced this today. Restarting the systemd service makes it reappear, but I don't see anything unusual when I run journalctl

[seekwhencer]

same here. running on a raspberry pi 4 8GB with docker. after serval hours the device is not listed.

[vguttmann]

Can confirm that this happens both with spotifyd and Raspotify when running alongside OSMC

[eladyn]

Thanks for the confirmations, I just found this issue over at the librespot repo, which seems to describe the exact same problem. So this could be fixed by checking for timeouts on the Ping-Pong commands in librespot.

[el-calavera]

For me, this is still a problem. (Raspberry Pi 3B, RaspberryOS)
I tried different versions, and v0.3.3 works as expected without disappearing.
Incidentally, since v0.3.4, Spotify-Connect lists the spotifyd client under "different networks". Maybe this has something to do with it.

[eladyn]

@el-calavera My guess is that the reason, why something changed between 0.3.3 and 0.3.4 is that we now only enable discovery on the local network, if you need it.

So previously, what you were seeing was the zeroconf-advertised instance - even if the actual spotify session got stale.
Now, if you supply spotifyd with credentials, it will only connect directly and authenticate and not enable discovery. So if you want the old behaviour back, you can just comment the username (and password) in your config.

All that may be completely wrong, because I'm just guessing what your setup might look like. 😅

[marktoman]

@eladyn Commenting out the credentials has solved the problem.

[el-calavera]

@eladyn Commenting out the credentials also worked for me. Thanks for the hint!

I wasn't aware this is an option, guess I should have studied the wiki more closely. ;)

(PS: my setup is simply a Pi3B running spotifyd, and I use Spotify clients for Android/Linux to connect within the same network.)

[BlackYps]

I have partial success with commenting out the credentials. I can now see the device listed when using the spotify desktop app, but on my android phone it keeps disappearing. I don't know if this is a general limitation of the android app, or if zeroconf is not working there for other reasons. Anyway, it seems to not be a problem with spotifyd but with something else.

[skeet70]

librespot-org/librespot#1129 may provide a path to fix this.

[Semmu]

I solved this issue with a workaround: I'm running spotifyd in a Docker container (shout out to https://github.com/hvalev/spotifyd-docker) and I'm periodically polling the Spotify API via Node-RED to see my currently online devices, and if my spotifyd device disappears, I just restart the container.

Although it is an "ugly" workaround, it has been working flawlessly since I (finally) implemented this.

[mabuckman]

@Semmu Would you be willing to share your polling script?

[rbozan]

Now that librespot-org/librespot#1129 is fixed can't we use a patch to use the master version of librespot until they make a release ?

[duczz]

@eladyn some news?

[eladyn]

Sorry for taking so long to reply, have been quite busy recently. For release planning on the librespot side of things, have a look here or here. As you can see, it might still take some time for the release to be usable.

Regarding just using the master: I'm not sure, if I'd be that confident shipping the unstable dev version of librespot to all users within a regular release of spotifyd due to similar reasons outlined in one of the linked threads. So I see two possible ways forward:

• We port spotifyd to librespot [dev] on a separate branch that interested users can try. This might also help the librespot project by discovering potential bugs before a release.
• We backport the ping-pong Mechanism to librespot 0.4. I haven't looked into it yet, so I can't tell, if it is as trivial as the PR you linked. But this could also be shipped within a spotifyd release, if necessary.

If you have any thoughts or would like to take a shot at whatever option you like best, that would be appreciated. I'm not sure, when I might get to it myself.

[Semmu]

@Semmu Would you be willing to share your polling script?

hey @mabuckman sorry for the veeery late reply, not sure if you still need my workaround, but here it is anyways.

• im running my whole smart-home setup via docker-compose, so everything is in containers, even spotifyd. i chose hvalev's images.
• the automations are implemented in node-red, for which i chose the official upstream container images.
• it can also talk to the spotify API via the node-red-contrib-spotify 3rd party package.
• i also expose the host's docker engine socket via socat in a very small container. this is needed so i can manipulate (e.g. restart spotifyd) containers from other containers (e.g. node-red).

this is the setup in general.

and the workaround itself is that i poll the spotify API's getMyDevices endpoint, and whenever i see that my spotifyd device is not included, i simply restart that container.

and the docker engine socket exposure looks like this:

Dockerfile

FROM alpine:3.17.3

ENV SOCKET="/var/run/docker.sock"
ENV PORT="2378"

RUN apk update && \
    apk upgrade && \
    apk add socat

# sh form of entrypoint, needed for env var substitution
ENTRYPOINT socat -d -d TCP4-LISTEN:$PORT,reuseaddr,fork UNIX-CONNECT:$SOCKET

docker-compose.yaml

services:
  docker-proxy:
    restart: always
    build: ./docker-proxy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    network_mode: host

[...]

this way i can do a simple POST request on its port and the docker engine will do what it needs to do.

this is a pretty dangerous solution from security point of view, since my whole docker API is exposed on an HTTP port, but my system is closed off, so i take the risk.

the flow looks like this:

hope it helps anyone!