I'm new to your codebase and the OpenRGB protocol, and I only have a single length LED strip to test on at the moment, so I can't guarantee I got this right, but it's working for me. I hope I've figured this out.
The header in def set_colors wasn't accounting for the additional "I" prepended to the buff on line 106. This resulted in the header telling the API that a calculated buffer size 4 shorter than the actual size.
The API would only read n-1 LEDs worth of data from the client. Since the server knows how many LEDs there are supposed to be, and since it's using pointers, it just kept advancing and reading by fixed offsets. The result being that the last LED in the strip was getting whatever hex happened to be in the next chunk of memory.
You can check it out by logging:
print(struct.calcsize(f"IH{3*(len(self.leds))}b{len(self.leds)}x"))
vs.
print(len(buff)) # After its all put together
@jath03, Thanks for the code.
I'm new to your codebase and the OpenRGB protocol, and I only have a single length LED strip to test on at the moment, so I can't guarantee I got this right, but it's working for me. I hope I've figured this out.
The header in
def set_colorswasn't accounting for the additional "I" prepended to the buff on line 106. This resulted in the header telling the API that a calculated buffer size 4 shorter than the actual size.The API would only read n-1 LEDs worth of data from the client. Since the server knows how many LEDs there are supposed to be, and since it's using pointers, it just kept advancing and reading by fixed offsets. The result being that the last LED in the strip was getting whatever hex happened to be in the next chunk of memory.
You can check it out by logging:
print(struct.calcsize(f"IH{3*(len(self.leds))}b{len(self.leds)}x")) vs. print(len(buff)) # After its all put together