Crash on handlePlayerCommand()
#150
Comments
|
Offtop: could you share your go-libtespot.service file? |
|
|
@2opremio How are you transfering playback to go-librespot? |
|
With https://github.com/zmb3/spotify , using my personal account. It has been working flawlessly for years with |
|
I can also reproduce the web API test at https://developer.spotify.com/documentation/web-api/reference/transfer-a-users-playback |
|
After adding the following patch: diff --git a/cmd/daemon/player.go b/cmd/daemon/player.go
index 1754206..efbf41f 100644
--- a/cmd/daemon/player.go
+++ b/cmd/daemon/player.go
@@ -149,6 +149,9 @@ func (p *AppPlayer) handlePlayerCommand(ctx context.Context, req dealer.RequestP
if err := proto.Unmarshal(req.Command.Data, &transferState); err != nil {
return fmt.Errorf("failed unmarshalling TransferState: %w", err)
}
+ fmt.Printf("request: %#v\n", req)
+ fmt.Printf("command data: %#v\n", req.Command.Data)
+ fmt.Printf("playback is nil: %t\n", transferState.Playback == nil)
p.state.lastTransferTimestamp = transferState.Playback.Timestamp
ctxTracks, err := tracks.NewTrackListFromContext(ctx, p.sess.Spclient(), transferState.CurrentSession.Context)I can confirm that the playback is nil (or incorrectly deserialized to nil) Here is are the logs with the patch applied: |
|
Here an example of the raw message received, before the crash: I would bet on the protobuf format being faulty/outdated. |
|
@devgianlu let me know if you need any other info |
|
I am not entirely sure what this should even do, the payload is empty: {"message_id":306658336,"target_alias_id":null,"sent_by_device_id":"webapi-cfe923b2d660439caf2b557b21f31221","command":{"endpoint":"transfer","data":"","options":{"restore_paused":"resume","restore_position":"last_known","restore_track":"always_play_something","retain_session":"do_not_retain"},"from_device_identifier":"webapi-cfe923b2d660439caf2b557b21f31221","logging_params":{}}}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. |
|
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)? |
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. |
|
You mean that you are intercepting the messages to the official client while transferring and you also get an empty message? |
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)? |
|
When playing in another device it works just fine |
I think this is solved then? The crash should not happen anymore. |
|
Yep, thanks a lot |
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.
The text was updated successfully, but these errors were encountered: