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
• [x] 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 #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

[pwall2222]

Also happens to me i have a MS-7B00 as my motherboard. And Im running the systemctl user process.

[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[bot]]

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[bot]]

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: https://github.com/librespot-org/librespot/issues/247 Note that the issue itself is closed because the underlying issue is discussed here: https://github.com/librespot-org/librespot/discussions/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.