Closed mattyoung101 closed 4 years ago
Just confirmed it is most likely due to TCP packet splitting. Take a look at this:
Successful decode of 8 availableBytes, 8 readBytes
02:38:26 DEBUG remote_debug.c:124: Received CMD_THRESHOLDS_SET, type=max, colour channel=2, value=145
02:38:27 DEBUG remote_debug.c:124: Received CMD_THRESHOLDS_SET, type=max, colour channel=2, value=163
Successful decode of 8 availableBytes, 8 readBytes
02:38:28 ERROR remote_debug.c:86: Failed to decode Omicontrol Protobuf command: varint overflow
02:38:28 DEBUG remote_debug.c:87: Diagnostic information. readBytes: 1, availableBytes: 1
02:38:28 ERROR remote_debug.c:86: Failed to decode Omicontrol Protobuf command: invalid wire_type
02:38:28 DEBUG remote_debug.c:87: Diagnostic information. readBytes: 7, availableBytes: 7
What's happening here is the message is being chunked into an 8 byte stream + a 1 byte, when it should be just 8 bytes. Not sure how to get around this issue?
To reproduce, it appears that Omicam must have the
waitKey
delay be something like 25 ms not 50 ms. Can't repro on 50ms.What happens basically is that about 1/2 to 1/4 of the time, when you adjust a slider, Omicam fails to parse the Protocol Buffer message it gets sent. Here's some example log output:
You can see that initially it fails claiming "invalid wire type" and "varint overflow" and then succeeds later on. I think this may be to do with TCP chunking, we may need to carry over the buffer to the next call of the function or something.