[GH-ISSUE #107] Transferring playback to go-librespot doesn't always work #72

New issue

Closed

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

kerem commented

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

Owner

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

I found that transferring playback to go-librespot doesn't always work.

Sometimes it switches back to the previous player. Other times the previous player becomes unresponsive, and only switching back and forth again fixes it.

It appears that this happens only when transferring playback after playback was transferred successfully before. So if it fails, switching to a different player and to go-librespot again typically works.

See: https://github.com/devgianlu/go-librespot/pull/106#discussion_r1782429113

I think the core issue is that the cluster update (hm://connect-state/v1/cluster) and the "transfer" player command (hm://connect-state/v1/player/command) are sometimes reversed so that the cluster update of the previous device comes after the transfer player command.

Originally created by @aykevl on GitHub (Oct 1, 2024). Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/107 I found that transferring playback to go-librespot doesn't always work. Sometimes it switches back to the previous player. Other times the previous player becomes unresponsive, and only switching back and forth again fixes it. It appears that this happens only when transferring playback after playback was transferred successfully before. So if it fails, switching to a different player and to go-librespot again typically works. See: https://github.com/devgianlu/go-librespot/pull/106#discussion_r1782429113 I think the core issue is that the cluster update (`hm://connect-state/v1/cluster`) and the "transfer" player command (`hm://connect-state/v1/player/command`) are sometimes reversed so that the cluster update of the previous device comes after the transfer player command.

kerem

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

closed this issue
added the
bug
label

kerem commented

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

Author

Owner

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

I have experienced this bug myself too and it has always been kind of a problem. My previous attempt at fixing this with librespot-java was this: github.com/librespot-org/librespot-java@d0ff31b4f4/player/src/main/java/xyz/gianlu/librespot/player/state/DeviceStateHandler.java (L174-L176)

@devgianlu commented on GitHub (Oct 1, 2024): I have experienced this bug myself too and it has always been kind of a problem. My previous attempt at fixing this with librespot-java was this: https://github.com/librespot-org/librespot-java/blob/d0ff31b4f476590c9c17401aac01a6762e4ba908/player/src/main/java/xyz/gianlu/librespot/player/state/DeviceStateHandler.java#L174-L176

kerem commented

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

Author

Owner

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

Sadly this doesn't seem to fix the bug entirely, though it is a whole lot better. I still sometimes get "bounced" after connecting to go-librespot.

@aykevl commented on GitHub (Oct 9, 2024): Sadly this doesn't seem to fix the bug entirely, though it is a whole lot better. I still sometimes get "bounced" after connecting to go-librespot.

kerem referenced this issue

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

[PR #72] [MERGED] fix: (skipping) ignore track index when track uri or track uid is available #191