[GH-ISSUE #705] spotify-player device disappears after some time

kerem commented

2026-03-02 23:47:20 +03:00

Owner

Originally created by @contonice on GitHub (Apr 5, 2025).
Original GitHub issue: https://github.com/aome510/spotify-player/issues/705

Describe the bug
I'm trying to use this app as a backend for a smart speaker.
My setup: raspberry pi with wired internet, usb sound card and speakers.
I am running the application in daemon mode using -d flag and systemd. Then, when I want to listen to music, I open spotify on my phone and use spotify connect to turn on the track on raspberry. This works immediately after running the script. But if a certain amount of time passes (one night for example), the spotify-player device will disappear. However, the application does not die, the process remains run in the system.

To Reproduce

Install an application with a flag to run as a daemon.
Change the ID in the config to your application created in the spotify api.
Launch the application with the -d flag.
Launch spotify on your phone and make sure that there is a spotify player in the list.
Wait a few hours.
Launch spotify on your phone again and see that the spotify player has disappeared.

Optional:
7) Kill the player process and launch it again (or use systemctl restart).
8) Open spotify on your phone.
9) spotify-player is working again.

Expected behaviour
As long as application working, there is spotify-player on phone.

Log and backtrace
Backtrace is empty.
Here is log:
https://drive.google.com/file/d/1AnGfBljq5IlkNGm4FwOR0mpmsixZhcmY/view

Environment

OS: Latest Raspberry Pi OS (Linux rpi 6.6.74+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.74-1+rpt1 (2025-01-27) aarch64 GNU/Linux)
Application version: 0.20.4
Application features: cargo install spotify_player --features daemon

Additional context

My systemctl config:

[Unit]
Description=Spotify Player daemon
After=network.target

[Service]
Type=forking
ExecStart=/home/contie/.cargo/bin/spotify_player -d
Restart=on-failure

[Install]
WantedBy=default.target

Originally created by @contonice on GitHub (Apr 5, 2025). Original GitHub issue: https://github.com/aome510/spotify-player/issues/705 **Describe the bug** I'm trying to use this app as a backend for a smart speaker. My setup: raspberry pi with wired internet, usb sound card and speakers. I am running the application in daemon mode using -d flag and systemd. Then, when I want to listen to music, I open spotify on my phone and use spotify connect to turn on the track on raspberry. This works immediately after running the script. But if a certain amount of time passes (one night for example), the spotify-player device will disappear. However, the application does not die, the process remains run in the system. **To Reproduce** 1) Install an application with a flag to run as a daemon. 2) Change the ID in the config to your application created in the spotify api. 3) Launch the application with the -d flag. 4) Launch spotify on your phone and make sure that there is a spotify player in the list. 5) Wait a few hours. 6) Launch spotify on your phone again and see that the spotify player has disappeared. Optional: 7) Kill the player process and launch it again (or use systemctl restart). 8) Open spotify on your phone. 9) spotify-player is working again. **Expected behaviour** As long as application working, there is spotify-player on phone. **Log and backtrace** Backtrace is empty. Here is log: https://drive.google.com/file/d/1AnGfBljq5IlkNGm4FwOR0mpmsixZhcmY/view **Environment** - OS: Latest Raspberry Pi OS (`Linux rpi 6.6.74+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.74-1+rpt1 (2025-01-27) aarch64 GNU/Linux`) - Application version: `0.20.4` - Application features: `cargo install spotify_player --features daemon` **Additional context** My systemctl config: ``` [Unit] Description=Spotify Player daemon After=network.target [Service] Type=forking ExecStart=/home/contie/.cargo/bin/spotify_player -d Restart=on-failure [Install] WantedBy=default.target ```

kerem added the

bug

label

2026-03-02 23:47:20 +03:00

kerem commented

2026-03-02 23:47:21 +03:00

Author

Owner

@arc-d3v commented on GitHub (Apr 24, 2025):

I was going to create an issue about this, it's true that when you go idle for 5-10 minutes, the streaming pauses.
Though I think the problem is not from spotify-player but librespot, but that makes spotify-player daemon, not really a daemon.

Another solution is to disable the streaming on spotify-player and use spotifyd instead. Spotifyd never dies idle and has a service for systemd.
You can use spotify-player using spotifyd as a device but it's not necessary but you'll likely need a spotify connect API for spotify-player (to make the device showing on the list of devices).

@arc-d3v commented on GitHub (Apr 24, 2025): I was going to create an issue about this, it's true that when you go idle for 5-10 minutes, the streaming pauses. Though I think the problem is not from spotify-player but librespot, but that makes spotify-player daemon, not really a daemon. Another solution is to disable the streaming on spotify-player and use spotifyd instead. Spotifyd never dies idle and has a service for systemd. You can use spotify-player using spotifyd as a device but it's not necessary but you'll likely need a spotify connect API for spotify-player (to make the device showing on the list of devices).

kerem commented

2026-03-02 23:47:22 +03:00

Author

Owner

@aome510 commented on GitHub (May 10, 2025):

Another solution is to disable the streaming on spotify-player and use spotifyd instead. Spotifyd never dies idle and has a service for systemd.
You can use spotify-player using spotifyd as a device but it's not necessary but you'll likely need a spotify connect API for spotify-player (to make the device showing on the list of devices).

Weird cause spotifyd also uses librespot under the hood, so the same thing should happen unless the version of librespot is different between spotify_player and spotifyd.

Looking into the logs, this seems to be the problem

2025-04-04T15:25:22.921036Z ERROR librespot_connect::spirc: ContextError: Error { kind: Unknown, error: StatusCode(502) }

so it's librespot issue but I don't know why it happened

@aome510 commented on GitHub (May 10, 2025): > Another solution is to disable the streaming on spotify-player and use spotifyd instead. Spotifyd never dies idle and has a service for systemd. You can use spotify-player using spotifyd as a device but it's not necessary but you'll likely need a spotify connect API for spotify-player (to make the device showing on the list of devices). Weird cause `spotifyd` also uses `librespot` under the hood, so the same thing should happen unless the version of `librespot` is different between `spotify_player` and `spotifyd`. Looking into the logs, this seems to be the problem ``` 2025-04-04T15:25:22.921036Z ERROR librespot_connect::spirc: ContextError: Error { kind: Unknown, error: StatusCode(502) } ``` so it's `librespot` issue but I don't know why it happened

kerem commented

2026-03-02 23:47:22 +03:00

Author

Owner

@arc-d3v commented on GitHub (May 10, 2025):

Another solution is to disable the streaming on spotify-player and use spotifyd instead. Spotifyd never dies idle and has a service for systemd.
You can use spotify-player using spotifyd as a device but it's not necessary but you'll likely need a spotify connect API for spotify-player (to make the device showing on the list of devices).

Weird cause spotifyd also uses librespot under the hood, so the same thing should happen unless the version of librespot is different between spotify_player and spotifyd.

Looking into the logs, this seems to be the problem
2025-04-04T15:25:22.921036Z ERROR librespot_connect::spirc: ContextError: Error { kind: Unknown, error: StatusCode(502) }    
so it's librespot issue but I don't know why it happened

This error is only showing only with spotify-player though. When I use spotify_connect with spotifyd, I don't get a 502 when I use a device other than spotify-player.
You can reproduce it pretty easily, connect spotify-player (streaming off) to spotify connect, and spotifyd to spotify connect, start any song with spotify-player while connected to spotifyd as a device, then you'll see the error. Do the same thing with but start the song with any backend device (phone or official app) and you get no error.

There are a lot of sync issue as well with spotify-connect connected in another backed device through spotify-connect, but that's another issue.

Though the error is showing at start, it doesn't cut the stream, the stream is cut off randomly after a few hours of use.

Seems it's related to #710 .

@arc-d3v commented on GitHub (May 10, 2025): > > Another solution is to disable the streaming on spotify-player and use spotifyd instead. Spotifyd never dies idle and has a service for systemd. > > You can use spotify-player using spotifyd as a device but it's not necessary but you'll likely need a spotify connect API for spotify-player (to make the device showing on the list of devices). > > Weird cause `spotifyd` also uses `librespot` under the hood, so the same thing should happen unless the version of `librespot` is different between `spotify_player` and `spotifyd`. > > Looking into the logs, this seems to be the problem > > ``` > 2025-04-04T15:25:22.921036Z ERROR librespot_connect::spirc: ContextError: Error { kind: Unknown, error: StatusCode(502) } > ``` > > so it's `librespot` issue but I don't know why it happened This error is only showing only with spotify-player though. When I use spotify_connect with spotifyd, I don't get a 502 when I use a device other than spotify-player. You can reproduce it pretty easily, connect spotify-player (streaming off) to spotify connect, and spotifyd to spotify connect, start any song with spotify-player while connected to spotifyd as a device, then you'll see the error. Do the same thing with but start the song with any backend device (phone or official app) and you get no error. There are a lot of sync issue as well with spotify-connect connected in another backed device through spotify-connect, but that's another issue. Though the error is showing at start, it doesn't cut the stream, the stream is cut off randomly after a few hours of use. Seems it's related to #710 .

kerem commented

2026-03-02 23:47:22 +03:00

Author

Owner

@arc-d3v commented on GitHub (May 31, 2025):

So after some test, I discovered that it happens with spotifyd as well but less often.
It happens when a tiny disconnection or a change on the network happens, librespot doesn't have anything to reconnect to spotify connect so the playback stops.
So you were right, it's only a librespot issue, not spotify player or spotifyd.

@arc-d3v commented on GitHub (May 31, 2025): So after some test, I discovered that it happens with spotifyd as well but less often. It happens when a tiny disconnection or a change on the network happens, librespot doesn't have anything to reconnect to spotify connect so the playback stops. So you were right, it's only a librespot issue, not spotify player or spotifyd.

kerem commented

2026-03-02 23:47:22 +03:00

Author

Owner

@glima commented on GitHub (Sep 22, 2025):

For me it's been a while no devices show up, regardless. It plays on my computer if I start afresh, but never showing anything in the devices bar. Give it some pauses and context switching and back, then playing on my laptop (Linux) does not work anymore, unless starting afresh:

@glima commented on GitHub (Sep 22, 2025): For me it's been a while no devices show up, regardless. It plays on my computer if I start afresh, but never showing anything in the devices bar. Give it some pauses and context switching and back, then playing on my laptop (Linux) does not work anymore, unless starting afresh: <img width="1896" height="318" alt="Image" src="https://github.com/user-attachments/assets/40b8ee1b-7c78-4a0f-abfb-2d19b610b5f8" />

kerem referenced this issue

2026-03-02 23:49:40 +03:00

[PR #417] [MERGED] miscellaneous fixes #753

kerem referenced this issue

2026-03-14 15:27:44 +03:00

[PR #417] [MERGED] miscellaneous fixes #1691

Rows
Columns

[GH-ISSUE #705] spotify-player device disappears after some time #417