Failsafe Output

[haich213]

Hi- Truly amazing program! Thank you.

It seems that the failsafe mode of a process engine does not hold the correct output. It will go into failsafe mode and output the correct values (hold last, full-on, scene et cetera) but will then transition to sending all zeros about 750-800 ms later. Also, it does not appear to wait for the 2.5 seconds sACN timeout before transitioning to failsafe status.

Using DMXRouter v1.11.0 on Windows 11 with sACN input and output.

-Haich

[fiverecords]

Hi Haich, thanks for the kind words and the detailed report.

Before digging in, a quick question that will change which fix applies: what sACN sender are you using, and is it being shut down deliberately (closing the project, disabling the patch, quitting the app) or is it just disappearing from the network (cable pulled, console crash, IP change)?

The reason it matters: per E1.31 §6.2.6, when a sender closes its stream deliberately it sets the "Stream Terminated" option bit on its final packets. The spec then lets the receiver release the universe immediately rather than waiting the 2.5 s source-loss timeout — the timeout is for unexpected loss, the terminated bit is for intentional loss. So if your sender is sending stream-terminated packets on the way out, DMXRouter going to failsafe before 2.5 s is actually correct behaviour: from its point of view the source said "I'm leaving", not "I might be back".

That said, your second observation — failsafe applying the correct values and then flipping to zeros ~800 ms later — does look like a real bug regardless of which path you're on, and I have a working hypothesis. Most consoles emit several stream-terminated packets spaced a few hundred ms apart (typical for ETC Eos, grandMA, Hog), and on the later packets the engine briefly re-emits a zero frame before settling back. If you can confirm the sender, I can either repro it here or ask you for a quick packet capture if it turns out to be something we don't have on hand.

Thanks again for taking the time to write it up.

[haich213]

Thanks for the explanation. I am using sACNView v3.0.0 as the sender, and you are correct that I was shutting the stream down deliberately. That is the situation where I see the Process Engine go into failsafe immediately, output the correct failsafe values and then switch to zeros after ~800ms. If I pull the cable instead of shutdown the stream, the process engine does wait the 2.5seconds and output the correct failsafe values indefinitely.

I did the same test using GrandMA3 onPC v2.3.2.0 outputting sACN and the failsafe behavior appears to be correct both when stopping the stream manually and also when pulling the cable. So it does appear to be related to the sender.

Happy to test other configurations if that helps.

Thanks,
-H