starred/go-librespot

Fork 0

mirror of https://github.com/devgianlu/go-librespot.git synced 2026-04-26 05:15:49 +03:00

[GH-ISSUE #104] "Pause" doesn't appear to send the correct paused state #70

New issue

Closed

opened 2026-02-28 14:25:07 +03:00 by kerem · 6 comments

kerem commented

2026-02-28 14:25:07 +03:00

Owner

Originally created by @aykevl on GitHub (Sep 30, 2024).
Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/104

So here's a minor issue I'm having.

When you press "pause" in Spotify Android (when connected to go-librespot), it pauses as expected. But when you wait a few seconds (10 or so) and resume, you can see it jumps for a very short time to the time it would have been had the player not been paused. This only happens for a split second, presumably because go-librespot sends an updated position when resuming.

When testing the same thing when connected to open.spotify.com (playing on open.spotify.com, controlled from Spotify Android), this does not happen. So it appears that open.spotify.com sends something different.

I looked at the message it sends to the API and it sends the following request when the web player is being paused:

method: PUT
URL: https://gew4-spclient.spotify.com/track-playback/v1/devices/aeab3d432a2699430b795a799b2dc54f7faa94e4/state
Body:

{
  "seq_num": 1727713694878,
  "state_ref": {
    "state_machine_id": "ChRH6ArMoOoPq_qqG9SoDgTzND1m8A",
    "state_id": "d6ca1a4d3e6d41beb60276fa399afffa",
    "paused": true
  },
  "sub_state": {
    "playback_speed": 0,
    "position": 74994,
    "duration": 424481,
    "media_type": "AUDIO",
    "bitrate": 256000,
    "audio_quality": "VERY_HIGH",
    "format": 11
  },
  "previous_position": 74994,
  "debug_source": "pause"
}

sub_state looks like PlayerState but for the rest I couldn't find an appropriate protobuf.
Also, there are a ton of fields I don't know the meaning of (such as seq_num and state_machine_id).

I guess I could try sending this as JSON, to see whether it works at all. If so, I could try to find (or reverse engineer) the protobuf.

@devgianlu do you maybe have any ideas?

Originally created by @aykevl on GitHub (Sep 30, 2024). Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/104 So here's a minor issue I'm having. When you press "pause" in Spotify Android (when connected to go-librespot), it pauses as expected. But when you wait a few seconds (10 or so) and resume, you can see it jumps for a very short time to the time it would have been had the player not been paused. This only happens for a split second, presumably because go-librespot sends an updated position when resuming. When testing the same thing when connected to open.spotify.com (playing on open.spotify.com, controlled from Spotify Android), this does not happen. So it appears that open.spotify.com sends something different. I looked at the message it sends to the API and it sends the following request when the web player is being paused: method: PUT URL: https://gew4-spclient.spotify.com/track-playback/v1/devices/aeab3d432a2699430b795a799b2dc54f7faa94e4/state Body: ```json { "seq_num": 1727713694878, "state_ref": { "state_machine_id": "ChRH6ArMoOoPq_qqG9SoDgTzND1m8A", "state_id": "d6ca1a4d3e6d41beb60276fa399afffa", "paused": true }, "sub_state": { "playback_speed": 0, "position": 74994, "duration": 424481, "media_type": "AUDIO", "bitrate": 256000, "audio_quality": "VERY_HIGH", "format": 11 }, "previous_position": 74994, "debug_source": "pause" } ``` `sub_state` looks like PlayerState but for the rest I couldn't find an appropriate protobuf. Also, there are a ton of fields I don't know the meaning of (such as `seq_num` and `state_machine_id`). I guess I could try sending this as JSON, to see whether it works at all. If so, I could try to find (or reverse engineer) the protobuf. @devgianlu do you maybe have any ideas?

kerem closed this issue

2026-02-28 14:25:07 +03:00

kerem commented

2026-02-28 14:25:08 +03:00

Author

Owner

@aykevl commented on GitHub (Oct 1, 2024):

I tested librespot, and it doesn't have this issue. So I guess I should investigate how they do this.

@aykevl commented on GitHub (Oct 1, 2024): I tested librespot, and it doesn't have this issue. So I guess I should investigate how they do this.

kerem commented

2026-02-28 14:25:08 +03:00

Author

Owner

@aykevl commented on GitHub (Oct 1, 2024):

Didn't investigate librespot too deeply, but did find that go-librespot doesn't set the PlaybackSpeed to 0 when paused. Fixing that, the weird paused behavior is gone in Spotify Android.

@aykevl commented on GitHub (Oct 1, 2024): Didn't investigate librespot too deeply, but did find that go-librespot doesn't set the PlaybackSpeed to 0 when paused. Fixing that, the weird paused behavior is gone in Spotify Android.

kerem commented

2026-02-28 14:25:08 +03:00

Author

Owner

@devgianlu commented on GitHub (Oct 1, 2024):

I looked at the message it sends to the API and it sends the following request when the web player is being paused:

The API they use on the web player is very different from the one in the desktop players, sometimes it is very confusing. To look at the desktop stuff you can use something like Telerik Fiddler from a Windows machine.

I tested librespot, and it doesn't have this issue. So I guess I should investigate how they do this.

Keep in mind that librespot uses a much older version (10+ years) of the Spotify internal API and may do things very differently or not do them at all.

@devgianlu commented on GitHub (Oct 1, 2024): > I looked at the message it sends to the API and it sends the following request when the web player is being paused: The API they use on the web player is very different from the one in the desktop players, sometimes it is very confusing. To look at the desktop stuff you can use something like Telerik Fiddler from a Windows machine. > I tested librespot, and it doesn't have this issue. So I guess I should investigate how they do this. Keep in mind that librespot uses a much older version (10+ years) of the Spotify _internal_ API and may do things very differently or not do them at all.

kerem commented

2026-02-28 14:25:08 +03:00

Author

Owner

@aykevl commented on GitHub (Oct 1, 2024):

The API they use on the web player is very different from the one in the desktop players, sometimes it is very confusing. To look at the desktop stuff you can use something like Telerik Fiddler from a Windows machine.

Good to know!

Unfortunately I'm making things difficult for myself and am running a linux/arm64 (Asahi Linux) system. The Spotify desktop application doesn't work here. I could reboot into MacOS and sniff the network from there I guess...

Keep in mind that librespot uses a much older version (10+ years) of the Spotify internal API and may do things very differently or not do them at all.

Yeah I'm aware. But it can maybe give an idea of what kind of action needs to take place.

@aykevl commented on GitHub (Oct 1, 2024): > The API they use on the web player is very different from the one in the desktop players, sometimes it is very confusing. To look at the desktop stuff you can use something like Telerik Fiddler from a Windows machine. Good to know! Unfortunately I'm making things difficult for myself and am running a linux/arm64 (Asahi Linux) system. The Spotify desktop application doesn't work here. I could reboot into MacOS and sniff the network from there I guess... > Keep in mind that librespot uses a much older version (10+ years) of the Spotify _internal_ API and may do things very differently or not do them at all. Yeah I'm aware. But it can maybe give an idea of what kind of action needs to take place.

kerem commented

2026-02-28 14:25:08 +03:00

Author

Owner

@devgianlu commented on GitHub (Oct 1, 2024):

Unfortunately I'm making things difficult for myself and am running a linux/arm64 (Asahi Linux) system.

Yeah definitely 😄. I have a Windows VM that allows me to do these tests in a constrained environment, but I guess that wound't work for you because of arm64...

Anyway, #106 seems to work for me.

@devgianlu commented on GitHub (Oct 1, 2024): > Unfortunately I'm making things difficult for myself and am running a linux/arm64 (Asahi Linux) system. Yeah definitely :smile:. I have a Windows VM that allows me to do these tests in a constrained environment, but I guess that wound't work for you because of arm64... Anyway, #106 seems to work for me.

kerem commented

2026-02-28 14:25:08 +03:00

Author

Owner

@aykevl commented on GitHub (Oct 1, 2024):

but I guess that wound't work for you because of arm64...

It would in theory, I can run linux arm64 VMs just fine. But Windows arm64 VMs just don't work for reasons I don't understand (I spent many hours trying to get it to work).
I do have a Windows ARM VM on MacOS though, which I sometimes use when I need to test something on Windows.

@aykevl commented on GitHub (Oct 1, 2024): > but I guess that wound't work for you because of arm64... It would in theory, I can run linux arm64 VMs just fine. But Windows arm64 VMs just don't work for reasons I don't understand (I spent many hours trying to get it to work). I do have a Windows ARM VM on MacOS though, which I sometimes use when I need to test something on Windows.

kerem referenced this issue

2026-02-28 14:26:12 +03:00

[PR #71] [MERGED] reload context if client didn't send the entire playlist #192