Decoding of outgoingPlayerState

[SvenGoldstein]

Hi there,

I'm trying to get the decoding for the outgoingPlayerState working but receive the following error message:

Error: invalid wire type 7 at offset 2.

Wireshark seems to tell me the same:

The incomingPlayerState works fine. Attached is a Wireshark trace of the communication. Could it be that the message format has changed recently ?

#rideOn!

trace.zip

[wiedmann]

It's definitely possible that the message format has changed since the definitions were created.

Unfortunately this is beyond my current ability to debug. An unknown wire type implies that the protobuf decoding failed. As far as I know, the valid wire types only go up to 5. This could happen if there were non-protobuf data in the packets that needs to be skipped.

You could also try looking at the zwift.proto file in zwift-mobile-api to see if there any fields that need to be added.

[bovreuil]

I'm just looking into the same problem with my dotnet code - it does seem to have changed

There seems to be an extra byte at the the start of the buffer in the outbound UDP message - this is effectively the change to get mine working (I haven't tested this code, so not submitting PR)

before:
let packet = clientToServerPacket.decode(buffer.slice(ret.offset, ret.offset + ret.info.length - 4))
after:
let packet = clientToServerPacket.decode(buffer.slice(ret.offset + 1, ret.offset + ret.info.length - 5))

[SvenGoldstein]

Yes, after a tutorial on how to decode protobuf (first experience with it) I also saw the strange first byte and couldn't figure out what it is doing.

@bovreuil 👍 I tried your suggestion and it almost worked. The following code change did the final trick, (I had to leave the end address as it is while only changing the start address to leave out the first byte):

let packet = clientToServerPacket.decode(buffer.slice(ret.offset + 1, ret.offset + ret.info.length - 4))

Now the outgoingPlayerState can be decoded again. Many thanks, guys !!

[bovreuil]

Ah -4 makes much more sense :-)

I just got confused because this is what I did in .net:
var reducedPayload = udp.Payload.Skip(1).Take(udp.Payload.Length - 5).ToArray();

But I discovered something else this evening - you only need the extra first byte when you are in 'just watching' mode - as soon as you are riding, then the extra byte is not there and the original code is correct

[SvenGoldstein]

But I discovered something else this evening - you only need the extra first byte when you are in 'just watching' mode - as soon as you are riding, then the extra byte is not there and the original code is correct

Indeed, I just saw that too. I will adapt my code accordingly, thank you very much ! Would you maybe share your .NET solution with me ? I find it kind of hard (and annoying :-)) to work with JavaScript (all these callbacks, whaaaa) and I'm more familiar with C#.

[bovreuil]

Yeah I'll try to get something up on GitHub in the next few weeks...