mirror of
https://github.com/devgianlu/go-librespot.git
synced 2026-04-26 21:35:49 +03:00
[GH-ISSUE #150] Crash on handlePlayerCommand() #92
Labels
No labels
bug
enhancement
pull-request
spotify-side
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/go-librespot#92
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @2opremio on GitHub (Nov 21, 2024).
Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/150
Using today's master:
This started happening systematically a couple of days ago.
This seems to be the culprit:
Probably a nil pointer? I haven't had time to take a look into it and won't until next week.
@szygmunt commented on GitHub (Nov 21, 2024):
Offtop: could you share your go-libtespot.service file?
@2opremio commented on GitHub (Nov 21, 2024):
@devgianlu commented on GitHub (Nov 21, 2024):
p.statecannot be nil because it is initialized beforehandlePlayerCommandeven has a chance to be called,transferStateis not a pointer, this leaves out onlytransferState.Playbackto be nil. Makes very little sense.@2opremio How are you transfering playback to go-librespot?
@2opremio commented on GitHub (Nov 21, 2024):
With https://github.com/zmb3/spotify , using my personal account. It has been working flawlessly for years with
spotifyd(and up until now, for a couple of weeks, withgo-librespot).@2opremio commented on GitHub (Dec 4, 2024):
I can also reproduce the web API test at https://developer.spotify.com/documentation/web-api/reference/transfer-a-users-playback
@2opremio commented on GitHub (Dec 4, 2024):
After adding the following patch:
I can confirm that the playback is nil (or incorrectly deserialized to nil)
Here is are the logs with the patch applied:
@2opremio commented on GitHub (Dec 4, 2024):
Here an example of the raw message received, before the crash:
I would bet on the protobuf format being faulty/outdated.
@2opremio commented on GitHub (Dec 4, 2024):
@devgianlu let me know if you need any other info
@devgianlu commented on GitHub (Dec 4, 2024):
I am not entirely sure what this should even do, the payload is empty:
I am guessing it's just a matter of making the device active for future playback requsts? The official client also seems to not do anything.
Anyways, I have pushed a simple fix to make it not crash.
@2opremio commented on GitHub (Dec 4, 2024):
I haven’t checked what the official client does. I will check later, but in all my tests, the official client does transfer playback. So either:
Maybe some sort of state (e.g. from the go-librespot token) causes a faulty message?
I will try to erase the go-librespot state too in case that helps. Do you want me to save any state and share it (privately if it involves the authentication token)?
@devgianlu commented on GitHub (Dec 4, 2024):
I doubt that is the issue, the behaviour I see in the official client is the same as go-librespot, perhaps because I don't have any state. Do you get this issue even you are playing on another device?
There's nothing of real interest in there, just authentication stuff.
@2opremio commented on GitHub (Dec 4, 2024):
You mean that you are intercepting the messages to the official client while transferring and you also get an empty message?
@devgianlu commented on GitHub (Dec 7, 2024):
I am not able to check what the official client is receiving because my proxy setup broke for some reason. What I was referring to is that transferring withtout a playback state does nothing on the official client too.
Do you get this issue even when you are playing on another device (e.g. there's a playback valid state)?
@2opremio commented on GitHub (Dec 11, 2024):
When playing in another device it works just fine
@devgianlu commented on GitHub (Dec 12, 2024):
I think this is solved then? The crash should not happen anymore.
@2opremio commented on GitHub (Dec 12, 2024):
Yep, thanks a lot