I encountered a bug in the E1.31 (sACN) input plugin not checking the start-code of an E1.31 packet.
According to E1.31-2018 alternate START codes (non null) should be treated the same way as stated in E1.11 (DMX) (section 8.5.3.3 and 8.5.4):
When using a sACN source which also sends sACN packets with alternate start code, e. g. an ETC eos console which uses 0xDD for per-address-priorities (sent every 0.8 to 1 seconds), QLC+ treats this packets like DMX data.All receiving devices other than in-line processing devices shall process the START Code and differentiate between those packets with NULL START Codes and those with Alternate START Codes. Devices shall not ignore START Codes by assuming that all packets received are NULL START Code packets.
The resulting behaviour are flickering channels in the frequency of the 0xDD packets, because the priorities (default 100 on eos) are treated as DMX values, thus jumping between DMX data and 100 every 0.8 to 1 seconds.
There exists a free software called sACNView (https://sacnview.org/) which can also send per-channel-priorities with 0xDD start code (just set the priority mode in the send window to per-address).
A list with registered alternate start codes can be found at ESTA https://tsp.esta.org/tsp/working_groups ... eCodes.php.
Further information on this could also be found here: https://support.etcconnect.com/ETC/FAQ/ ... r_ETCnomad
The problem also exists on QLC+ 4.12.2.
The simplest fix would be to check the start code of incoming sACN packets and ignore all, which are not zero.
Thanks
Best regards
Johannes Felber
