Artnet flickering bug characterized

[nmaddix]

I wrote about this in a previous thread but I've got more information and I'd like to summarize here for clarity.

I've discovered what appears to be a bug in QLC+ that creates jittery output (flickering) when using Artnet tied to an H802RA LED pixel controller, starting in version 4.12.0 and later. Version 4.11.2 and earlier does not exhibit this problem.

My hardware:

Macbook PRO -> USB ethernet adapter -> unmanaged switch -> H802RA -> LED strips

Here are videos that illustrate the problem:

With jitter:

https://www.dropbox.com/s/oqe1b44j2pi7i ... r.mov?dl=0

Without jitter:

https://www.dropbox.com/s/4dpy2pj119h7q ... r.mov?dl=0

The problem starts as soon as a 2nd universe is enabled for the same Artnet adpter. I.e. as soon as the "Output" box is checked in the line that is already enabled for a different universe. In my case (see attached images) this is line 5, i.e. 192.168.6.5.

No data needs to be sent to this 2nd universe in order for the problem to occur, suggesting that perhaps some kind of keepalive data is being sent out that is conflicting with the data already going out for the first universe.

I've narrowed down the version where this problem starts. QLC+ versions 4.11.2 and before do not show this problem at all, while versions 4.12.0 through 4.12.3 (tested today) all show the issue.

I've tested the native OSX version as well as the native Windows version with the same result. The Windows test was on the same Mac using Parallels, however, as I do not have access to a PC to test.

I have also tested using 2 different ethernet adapters with the same result, a cheap USB ethernet adaptor and an Apple Thunderbolt to Ethernet adapter.

I've also tested broadcast and unicast to the controller with the same result.

For reference, I have not seen any jittery output with other lighting software and the exact same hardware configuration. I have tried Lightjams, Arena, Onyx, and Madmapper. So while this might be related to some kind of idiosyncrasy of the H802RA, it seems to also be an issue unique in QLC+.

Attached is the project file I used in the demos. Simply tick the Output box in the same Artnet line that's already used, as shown in the attached image, to get the jitter to start. Unticking the box results immediately in normal operation.

I did a broad stroke DiffMerge of the source code between versions 4.11.2. and 4.12.0 and found only one difference in plugins/arntnet/src/artnetcontroller.cpp on line 146, a single character | changed to & in the function ArtNetController::removeUniverse(). This could be related, though I'm not familiar with the code beyond a quick glance so grasping at straws a bit here.

I also looked at the release notes for 4.12.0 and noticed the line “engine: reworked to achieve multithreaded universes and properly handle fade transitions”. This strikes me as a possible place to look as well.

[mcallegari]

First off, please do not hijack the entire forum with your issue.
Just open one single discussion and let's discuss there.

The difference between 4.11 and 4.12 is that 4.11 was always sending ordered universes data out, while 4.12 doesn't guarantee an order cause it process universe data in parallel.
Having said that, on the network you will see one packet for universe 1 and one packet for universe 2, alternating in "random" order. You can verify that with Wireshark.
In theory a good ArtNet receiver should not have issues with that.

If, instead, universe 2 is actually overwriting universe 1 data, then it's a bug.

Have you tried to use both "full" and "partial" data transmission?
Does it make any difference?

I'll try to make some tests when I find some time.

[nmaddix]

Thanks for taking a look Massimo. I certainly did not intend to hijack the forum, but simply to keep things organized. That previous thread was so full of theories and back and forth as to be unreadable.

I have tried full and partial, with the same result.

Whether the H802RA is a "good" Artnet receiver is certainly up for debate, but it is a very popular one.

Might it be possible to set up a configuration toggle to revert back to sending ordered universe data? Could I toggle that in the code somewhere and compile my own version?

Thanks again.

[GGGss]

Massimo,

Rest assured that we have thoroughly discussed all possible issues concerning this problem. I have a telephone call with Maddix limiting possible issues back to QLC+.
Since I have not seen or experienced the same problems, I suggested Maddix to start a new thread.

Kind regards,

[mcallegari]

Might it be possible to set up a configuration toggle to revert back to sending ordered universe data? Could I toggle that in the code somewhere and compile my own version?

Not at all!
See this: https://www.qlcplus.org/forum/viewtopic ... 17&t=12638

It's impossible now to revert to the previous behaviour or add a "toggle".
That rework has been huge and it has proven to have several benefits to the overall architecture.

I'm thinking if there is a way to "order" universes in the ArtNet plugin, but most likely it would add a bottleneck.

[ambra]

I just stumbled upon this problem. I'm using similar controllers as mmaddix. I have ArtNet-DMX controller with 2 outputs and H803SA SPI controller for smart strips. I'm using just the first output/universe.

Now, I noticed that this behavior occurs when I click on QLCplus window or when I maximize it.

Here's a video with the behavior.
I verified that this behavior exists in following versions:

• 4.12.1
  4.12.2
  4.12.3

but it doesn't exist in 4.11.2.
It's present both on Windows and Linux.

I'm not sure if this behavior is caused by both universes being output in parallel, but certainly clicking or resizing windows should not trigger it.
I didn't have time to look into it a little better, but I'm wondering has anyone managed to solve this problem without reverting to old versions?
Regards!

[sandinak]

Not that it should matter .. but have you tried using Unicast vs Multicast? Eg .. target the specific IP for the H803SA for both U?

[ambra]

Not that it should matter .. but have you tried using Unicast vs Multicast? Eg .. target the specific IP for the H803SA for both U?

I haven't tried that. That might be a good idea. When I get some time, I will try that.

[mcowper]

I came across this thread when having the same problem with version 4.12.7. I have just downgraded to 4.11.2 and the problem seems to have gone away. Is there any work being done on fixing this in newer versions? I would be happy to test. Thanks.

[mcallegari]

Please try the latest test version and switch to "Standard" transmission mode.

[mcowper]

In 4.12.7 (which I think is the latest) I only see "Full" and "Partial" transmission modes. Am I missing something? I've tried both "Full" and "Partial" with the same results. I'm happy to try anything that you'd like.

I've been using 4.11.2 and see that I do still have some random flickering issues. Much less than with the newer versions. There are two flickering issues. One is just some random flickers. That is still there in 4.11.2, it just happens less. The other is one LED in a strip flickering at the end of a universe. I suspect the problem has to do with 510 channels being all you can use in one universe of RGB lights. That problem is completely solved by downgrading to 4.11.2.

[mcallegari]

*TEST* versions are available here
viewtopic.php?t=3135

or if you have a GitHub account, on Github, in the "Actions" area where you can download artifacts of each build
https://github.com/mcallegari/qlcplus/a ... mcallegari

[mcowper]

I'm running Linux. I probably should have mentioned that earlier. I do have access to test on a Mac. The only test download of a newer 4.12.x version that I saw was for WIndows. I do have a GitHub account. I've not used artifacts and couldn't figure that out right away. I did download the source and build the 4.12.8 version and tried it (only on Linux). I'm still seeing both types of flickering with it. I don't see a "standard" transmission mode option. I've tried both "full" and "partial". Thanks.

[mcallegari]

If you use Linux you can use automated builds for various distros
https://software.opensuse.org/download. ... us-qt5-git

I need to restore a link to this in the new website [EDIT: Done]

[mcowper]

That version, set with standard mode, makes all of the flickering stop. However, now there is a delay when I do something before the lights change. The amount of delay varies. It's around a couple of seconds. It's also not always the same in all universes, although it seems to be the same delay within any given universe. I've tried a different controller (MagicQ) and it is the same way. No flickers, but delays. I appreciate the work that you are doing on this. Please let me know if there is anything else you'd like me to try.

[mcowper]

I've done some more testing. I set up a packet sniffer and looked at the timing of the artnet packets being sent. They are sent immediately so I'm thinking the hardware has a problem. It's a T8K.NET console. I still don't understand how it was responding immediately, but with flickering, with the older versions and responding with a delay with this version. I'm going to try to return the console under warranty and/or get a different type.

[mcowper]

After more studying of the Art-Net protocol I think that I know what is happening. In Partial or Full modes it looks like QLC+ is sending Art-Net packets with OpCode ArtDMX very fast. I think by the Art-Net standard you should only send changes plus keep-alives every 4 seconds. (And in the spec right after it says 4 seconds it recommends 800-1000ms.) It looks like that is what you are doing with the mode set to Standard every 2 seconds. I think the T8K.NET Console that I am using was having problems with the rapid packets and just couldn't handle it causing the flickering in Full or Partial modes. In Standard mode I think the delay is caused by the T8K.NET Console being in synchronous mode and buffering the ArtDMX data packets waiting for a ArtSync packet or a timeout to send the output to the lights. It shouldn't do it that way. It should start out in non-synchronous mode and work fine with the data that QLC+ sends in Standard mode. I'm communicating with the company that I got the console from to see if they can fix that. I've also worked out a way to use scapy (a Python networking tool) to automatically send ArtSync packets after QLC+ sends a ArtDMX packet. I can't test that today. I will test it tomorrow and report here on how it works. I really appreciate all of your help.

[mcallegari]

Hi Mike, thanks for the heads up.
Yeah, QL+ was missing the standard implementation for years because of architectural limitations that should be solved now.
The ArtDmx interval I chose I think is the same of MA. Being the industry standard I opted for a safe timing.
Changing it is trivial if you can build from sources:
https://github.com/mcallegari/qlcplus/b ... er.cpp#L28

ArtSync is an option I haven't evaluated and to be honest I would have difficulties to test it since I don't have a LED wall with me

[mcowper]

My workaround with scapy didn't work. I'm getting some different firmware from the hardware manufacturer that I hope will fix it. They do synchronous mode by default, which is not correct according to the Art-Net standard. Supposedly they have some firmware that I can flash which will make it use non-synchronous mode.

If I find the time I may take a look at the QLC+ Art-Net plugin code and see if I can add support for ArtSync.

[mbobo10]

Hi,

Is there a solution with this controller ? I have the same bug problem.

Thanks