[GH-ISSUE #345] Stop playing after client disconnect

kerem commented

2026-02-27 19:29:31 +03:00

Owner

Originally created by @patrickjane on GitHub (Jul 6, 2019).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/345

Currently, when I close my spotify application on the desktop, librespot continues playing. In order to stop it, I have to reopen the desktop application and connect to librespot again, and then stop it.

Would there be a way for librespot to detect the disconnect of the client application so it can stop playback?

Originally created by @patrickjane on GitHub (Jul 6, 2019). Original GitHub issue: https://github.com/librespot-org/librespot/issues/345 Currently, when I close my spotify application on the desktop, librespot continues playing. In order to stop it, I have to reopen the desktop application and connect to librespot again, and then stop it. Would there be a way for librespot to detect the disconnect of the client application so it can stop playback?

kerem

2026-02-27 19:29:31 +03:00

closed this issue
added the
wontfix
label

kerem commented

2026-02-27 19:29:32 +03:00

Author

Owner

@ashthespy commented on GitHub (Jul 18, 2019):

This is how Spotify Connect is supposed to work. Multiple clients communicate commands, and only the active device acts on it.
So in your scenario - what happens if you have three (phone, desktop and librespot) devices - which one should it keep track of to stop playback?

@ashthespy commented on GitHub (Jul 18, 2019): This is how Spotify Connect is supposed to work. Multiple clients communicate commands, and only the active device acts on it. So in your scenario - what happens if you have three (phone, desktop and librespot) devices - which one should it keep track of to stop playback?

kerem commented

2026-02-27 19:29:32 +03:00

Author

Owner

@patrickjane commented on GitHub (Jul 18, 2019):

What do you mean with "Multiple clients communicate commands" and "active device acts on it"?
I assume we have 1 server with librespot which is doing the music playback, and, in your scenario, multiple clients (devices/mobile phones/spotify client applications).

I have never had this multi-client scenario. However, in general, the opened spotify app is showing the playback progress, and thus seems to have some actual "live" connection (in addition to just issueing playback commands), although of course this might be totally client side.

I have never tried with several devices, so I can only make a guess how it would behave, but lets assume I connect my iPhone, and start a song. The app on the iPhone will show the playback progress, and music will be played by the server/librespot.
If I start a song on a second device, according to your explanation, this would lead to the server switching to the other song.
The first device, however, would still show playback progress for its song, which - in my opinion - could already be considered a bug, because its wrong/misleading.

I think the most comfortable/intuitive behaviour would be:

Device 1 starts playback of song 1
Server starts playing song 1
Device 1 shows song 1 is playing
Device starts playback of song 2
Server starts playing song 2
Device 1 shows stopped playback

In regards of my original question, I think the most comfortable/intuitive behaviour would be:

Device 1 starts playback of song 1
Server starts playing song 1
Device 1 shows song 1 is playing
Device 1 closes the spotify app
Server stops playback

As stated, I have no technical knowledge about this, and of course, if the client does not issue any command upon closing the app, it will never be possible for the server/librespot to detect a disconnecting client. I don't know if there would be other ways to detect this.

I was just asking this question because normally on all my devices I just shutdown the app if I want to stop listening to music, but only when playing on librespot, I find myself reopening again all the time, to first stop the playback before shutting down the app.

@patrickjane commented on GitHub (Jul 18, 2019): What do you mean with "Multiple clients communicate commands" and "active device acts on it"? I assume we have 1 server with librespot which is doing the music playback, and, in your scenario, multiple clients (devices/mobile phones/spotify client applications). I have never had this multi-client scenario. However, in general, the opened spotify app is showing the playback progress, and thus *seems* to have some actual "live" connection (in addition to just issueing playback commands), although of course this might be totally client side. I have never tried with several devices, so I can only make a guess how it would behave, but lets assume I connect my iPhone, and start a song. The app on the iPhone will show the playback progress, and music will be played by the server/librespot. If I start a song on a second device, according to your explanation, this would lead to the server switching to the other song. The first device, however, would still show playback progress for its song, which - in my opinion - could already be considered a bug, because its wrong/misleading. I think the most comfortable/intuitive behaviour would be: 1) Device 1 starts playback of song 1 2) Server starts playing song 1 3) Device 1 shows song 1 is playing 4) Device starts playback of song 2 5) Server starts playing song 2 6) Device 1 shows stopped playback In regards of my original question, I think the most comfortable/intuitive behaviour would be: 1) Device 1 starts playback of song 1 2) Server starts playing song 1 3) Device 1 shows song 1 is playing 4) Device 1 closes the spotify app 5) Server stops playback As stated, I have no technical knowledge about this, and of course, if the client does not issue any command upon closing the app, it will never be possible for the server/librespot to detect a disconnecting client. I don't know if there would be other ways to detect this. I was just asking this question because normally on all my devices I just shutdown the app if I want to stop listening to music, but only when playing on librespot, I find myself reopening again all the time, to first stop the playback before shutting down the app.

kerem commented

2026-02-27 19:29:32 +03:00

Author

Owner

@ashthespy commented on GitHub (Jul 18, 2019):

What do you mean with "Multiple clients communicate commands" and "active device acts on it"?
I assume we have 1 server with librespot which is doing the music playback, and, in your scenario, multiple clients (devices/mobile phones/spotify client applications).

I have never had this multi-client scenario. However, in general, the opened spotify app is showing the playback progress, and thus seems to have some actual "live" connection (in addition to just issueing playback commands), although of course this might be totally client side.

Pulled from librespot-org/spotify-connect-resources
####Spotify Connect control This also looks like it is controlled through GAIA, via SpircManager. It appears that once a connection to a Connect speaker has been done over the local network, all playback control is done through Spotify servers. Again, this needs to be reversed and documented.

To build on that - When you login, each device connects to the Spotify servers and registers their presence. Subsequently, state updates (play/pause/volume/track etc etc) are pushed to all the devices, but only the active device plays music. So in essence, you have multiple devices, that can be either controllers or output devices. The only server here is Spotify's own servers - the reset are all clients.

If I start a song on a second device, according to your explanation, this would lead to the server switching to the other song.
The first device, however, would still show playback progress for its song, which - in my opinion - could already be considered a bug, because its wrong/misleading.

The device will continue tracking the state - but also display that it's playing on a different device.
Try playing around with multiple sessions with the desktop client and http://play.spotify.com/
You will see that playback will continue irregardless as other clients connect and disconnect - this is by design.

@ashthespy commented on GitHub (Jul 18, 2019): >What do you mean with "Multiple clients communicate commands" and "active device acts on it"? I assume we have 1 server with librespot which is doing the music playback, and, in your scenario, multiple clients (devices/mobile phones/spotify client applications). > >I have never had this multi-client scenario. However, in general, the opened spotify app is showing the playback progress, and thus seems to have some actual "live" connection (in addition to just issueing playback commands), although of course this might be totally client side. Pulled from [`librespot-org/spotify-connect-resources`](https://github.com/librespot-org/spotify-connect-resources/blob/master/ROADMAP.md) ####Spotify Connect control This also looks like it is controlled through GAIA, via SpircManager. It appears that once a connection to a Connect speaker has been done over the local network, all playback control is done through Spotify servers. Again, this needs to be reversed and documented. To build on that - When you login, each device connects to the Spotify servers and registers their presence. Subsequently, state updates (play/pause/volume/track etc etc) are pushed to all the devices, but only the active device plays music. So in essence, you have multiple devices, that can be either controllers or output devices. The only server here is Spotify's own servers - the reset are all clients. >If I start a song on a second device, according to your explanation, this would lead to the server switching to the other song. The first device, however, would still show playback progress for its song, which - in my opinion - could already be considered a bug, because its wrong/misleading. The device will continue tracking the state - but also display that it's playing on a different device. Try playing around with multiple sessions with the desktop client and http://play.spotify.com/ You will see that playback will continue irregardless as other clients connect and disconnect - this is by design.

kerem commented

2026-02-27 19:29:32 +03:00

Author

Owner

@kingosticks commented on GitHub (Jul 18, 2019):

If I start a song on a second device

Where is this song's audio actually playing? The second device, the first device, or librespot? If we assume you selected librespot to play the audio (so it remains the active device) then yes, librespot will start playing that new song. At that point both the first and second devices will show the current playback status for that new song. What you described ("The first device, however, would still show playback progress for its song") does not happen.

This is marked as "won't fix" because librespot mimics Spotify's Connect behaviour. The behaviour you want is something else.

@kingosticks commented on GitHub (Jul 18, 2019): > If I start a song on a second device Where is this song's audio actually playing? The second device, the first device, or librespot? If we assume you selected librespot to play the audio (so it remains the active device) then yes, librespot will start playing that new song. At that point both the first and second devices will show the current playback status for that new song. What you described ("The first device, however, would still show playback progress for its song") does not happen. This is marked as "won't fix" because librespot mimics Spotify's Connect behaviour. The behaviour you want is something else.

kerem commented

2026-02-27 19:29:32 +03:00

Author

Owner

@patrickjane commented on GitHub (Jul 18, 2019):

I see.

So do you think there would be any way at all to achieve this? E.g. is maybe librespot issueing events when a client disconnects, so I could script something to work around this?

@patrickjane commented on GitHub (Jul 18, 2019): I see. So do you think there would be any way at all to achieve this? E.g. is maybe `librespot` issueing events when a client disconnects, so I could script something to work around this?

kerem commented

2026-02-27 19:29:32 +03:00

Author

Owner

@ashthespy commented on GitHub (Jul 18, 2019):

Not explicitly in it's current from - but you can jump in around: github.com/librespot-org/librespot@4e3576ba7c/connect/src/spirc.rs (L473-L481)

Notice how we ignore messages that are not for us
github.com/librespot-org/librespot@4e3576ba7c/connect/src/spirc.rs (L483-L487)

Hope that helps!

@ashthespy commented on GitHub (Jul 18, 2019): Not explicitly in it's current from - but you can jump in around: https://github.com/librespot-org/librespot/blob/4e3576ba7c6146cf68e1953daeec929d619b26b1/connect/src/spirc.rs#L473-L481 Notice how we ignore messages that are not for us https://github.com/librespot-org/librespot/blob/4e3576ba7c6146cf68e1953daeec929d619b26b1/connect/src/spirc.rs#L483-L487 Hope that helps!

kerem commented

2026-02-27 19:29:32 +03:00

Author

Owner

@patrickjane commented on GitHub (Jul 18, 2019):

Not so much, as I am not a rust programmer, but thanks anyway :)

@patrickjane commented on GitHub (Jul 18, 2019): Not so much, as I am not a rust programmer, but thanks anyway :)

kerem commented

2026-02-27 19:29:32 +03:00

Author

Owner

@ashthespy commented on GitHub (Jul 18, 2019):

I just checked, there is no "event" that is triggered when a device is closed, kMessageTypeGoodbye is when the user logs out.

[2019-07-18T14:27:24Z INFO  librespot_connect::spirc] kMessageTypeNotify "AshPad"
[2019-07-18T14:27:29Z INFO  librespot_connect::spirc] kMessageTypeNotify "AshPad"
[2019-07-18T14:30:03Z INFO  librespot_connect::spirc] kMessageTypeNotify "AshPad"
[2019-07-18T14:30:22Z INFO  librespot_connect::spirc] kMessageTypeNotify "AshPad"
[2019-07-18T14:50:03Z INFO  librespot_connect::spirc] kMessageTypeHello "Web Player (Firefox)"
[2019-07-18T14:50:04Z INFO  librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)"
[2019-07-18T14:50:33Z INFO  librespot_connect::spirc] kMessageTypeHello "Nokia 3310"
[2019-07-18T14:50:33Z INFO  librespot_connect::spirc] kMessageTypeHello "Nokia 3310"
[2019-07-18T14:50:33Z INFO  librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)"
[2019-07-18T14:50:33Z INFO  librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)"
[2019-07-18T14:50:46Z INFO  librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)"
[2019-07-18T14:50:47Z INFO  librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)"
[2019-07-18T14:50:47Z INFO  librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)"
[2019-07-18T14:51:00Z INFO  librespot_connect::spirc] kMessageTypeNotify "Nokia 3310"
[2019-07-18T14:51:05Z INFO  librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)"
[2019-07-18T14:51:56Z INFO  librespot_connect::spirc] kMessageTypeNotify "AshPad"
[2019-07-18T14:52:04Z INFO  librespot_connect::spirc] kMessageTypeGoodbye "AshPad"
[2019-07-18T14:52:13Z INFO  librespot_connect::spirc] kMessageTypeNotify "AshPad"
[2019-07-18T14:52:13Z INFO  librespot_connect::spirc] kMessageTypeNotify "AshPad"
[2019-07-18T14:52:13Z INFO  librespot_connect::spirc] kMessageTypeHello "AshPad"
[2019-07-18T14:52:13Z INFO  librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)"

@ashthespy commented on GitHub (Jul 18, 2019): I just checked, there is no "event" that is triggered when a device is closed, `kMessageTypeGoodbye` is when the user logs out. ``` [2019-07-18T14:27:24Z INFO librespot_connect::spirc] kMessageTypeNotify "AshPad" [2019-07-18T14:27:29Z INFO librespot_connect::spirc] kMessageTypeNotify "AshPad" [2019-07-18T14:30:03Z INFO librespot_connect::spirc] kMessageTypeNotify "AshPad" [2019-07-18T14:30:22Z INFO librespot_connect::spirc] kMessageTypeNotify "AshPad" [2019-07-18T14:50:03Z INFO librespot_connect::spirc] kMessageTypeHello "Web Player (Firefox)" [2019-07-18T14:50:04Z INFO librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)" [2019-07-18T14:50:33Z INFO librespot_connect::spirc] kMessageTypeHello "Nokia 3310" [2019-07-18T14:50:33Z INFO librespot_connect::spirc] kMessageTypeHello "Nokia 3310" [2019-07-18T14:50:33Z INFO librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)" [2019-07-18T14:50:33Z INFO librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)" [2019-07-18T14:50:46Z INFO librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)" [2019-07-18T14:50:47Z INFO librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)" [2019-07-18T14:50:47Z INFO librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)" [2019-07-18T14:51:00Z INFO librespot_connect::spirc] kMessageTypeNotify "Nokia 3310" [2019-07-18T14:51:05Z INFO librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)" [2019-07-18T14:51:56Z INFO librespot_connect::spirc] kMessageTypeNotify "AshPad" [2019-07-18T14:52:04Z INFO librespot_connect::spirc] kMessageTypeGoodbye "AshPad" [2019-07-18T14:52:13Z INFO librespot_connect::spirc] kMessageTypeNotify "AshPad" [2019-07-18T14:52:13Z INFO librespot_connect::spirc] kMessageTypeNotify "AshPad" [2019-07-18T14:52:13Z INFO librespot_connect::spirc] kMessageTypeHello "AshPad" [2019-07-18T14:52:13Z INFO librespot_connect::spirc] kMessageTypeNotify "Web Player (Firefox)" ```

Rows
Columns

[GH-ISSUE #345] Stop playing after client disconnect #228