I was chatting in a different thread about this issue and have gotten some more information together about it. What happens is if we have a DMXout Chop and we set the network address target to be an mdns name which is unreachable the main thread hangs while attempting to connect and an retries indefinitely. I think the best thing to do would be to move it to a separate thread if possible. The infinite retry is good because then it will connect once it becomes available. Just the blocking the main thread is the issue. I asked gemini about it and it seems to be related to windows update KB5065789 https://youtu.be/kww8Y4ADDTE There is another main thread blocking issue with the video device in top “options” camera settings. When accessing the same menus inside OBS there is no main thread blocking and the changes can be applied in real time to see their effects.
This is a regression in 2025.31740 that causes the cook on the main thread to wait for the network thread to finish resolving the address (whereas before that would only occur on teardown, such as in the case of CHOP deactivation). I’ve fixed the bug and it will be in the next official build we release: 2025.31890+. The bug is not in 2025.31550 so I recommend downgrading for now as a work around.
Thanks for the report.
Good to know! I think the camera properties blocking main thread is still a thing. Although it is less of a big deal. Still I think that properties window should be created outside of the main thread too. That way you can actually see what your changes are doing. It’s the type of window shown in the screen shot.
Yeah, that dialog logic is fairly old and there’s no reason it couldn’t be moved to a different thread, but it hasn’t been a high priority to do so. I understand the inconvenience of it though.
Doing some more testing with DMX pops this time and noticing a 2 second oscillation in the network output I tried version 2025 31310, 31550, and 31760 on a couple machines and the behavior seems consistent. Here is a sample file with some trails from the different versions. Also noticing that the rate is lower if TD window is not in focus. The big spikes on the 31550 version is the focus difference. Any workarounds for sending ~80 universes without drops every 2-3 seconds? Would using multiple dmx out pops help?
Thanks
packet_rate_sample.toe (19.5 KB)
I see the oscillation occurring in the packet_rate channel, but oddly enough the packets_sent is comparatively smooth (albeit, with a stutter every now and again), which makes me wonder if there is an error in calculating the packet rate. Do you notice similarly strange behavior of the packet rate on the receiving side?
Also, the DMX Out POP in the attached project is sending out 22565 universes, not 80. The Routing Table is a feature for routing universes to specific network addresses and cannot be used to constrict or send just a subset of universes, as the DMX Out POP will send out all the universes of its input DMX Fixture POPS regardless of what is in the Routing Table.
EDIT: the number of universes can be viewed using the DMX Fixture/Out POP’s Info CHOP num_universes channel.
Yes at we are seeing a stutter on the leds and fps drop in td at the same cadence when using the dmx out pop. When using the dmx out chop I am seeing odd behavior too with lower than expected FPS. In perform mode the fps is always lower regardless of focus status. When in editor mode and in focus fps is low and when out of focus FPS is high. https://youtu.be/0LEtuZz7y70
Are the test-cases the same? In the video you’re sending 80 universes, but like I said earlier, in the attached DMX Out POP example you’re sending 22565 universes/packets every single frame.
Regarding the DMX Out CHOP send rate issue: I’ll test and see if I can reproduce.
Oh yeah I did not mean to be sending more the ~80 universes! No wonder that was struggling. I am still learning how to use the dmx pops. I have 22 strips of 624 pixels and I am starting with a 624x22 top and each strip uses about 4 universes. There are 170 channels unused at the end of the 4th universe so the next strip can start on universe 5 how would you suggest I do that with pops? When I try to put the 170 channel gap the number of universes goes way up because it’s doing it after every pixel instead of every row. Thanks again.
packet_rate_sample.toe (5.3 KB)
Hi @kendrick90,
in your case it’s important to understand that every strip is a fixture, and every fixture should be represented by a single primitive. When using the TOP to POP, the result is individual points that when passed on to the DMX Fixture POP would each represent a fixture. You can use a Connectivity POP and connect individual points along one dimension into Linestrips.
Just with the default settings, the result in your case is 22 Linestrips with 624 points each. This now has the representation of 22 fixtures with 624 light points for each fixture.
To now use the auto layout function of the DMX Fixture POP, first set the Channel Gap parameter to 170 and select “By Components” from the Quantize Universe parameter.
Hope this helps
cheers
Markus
packet_rate_sample.15.toe (5.5 KB)