sACN Merge Unexpected Behavior

[SirDur]

While using the Process Engines to change sACN data from one VLAN to another, as soon as I enable the Process Engine, it starts outputting zero values, despite the input VLAN having no sACN data. At that point, it feels like DMX Router is generating new data instead of just outputting what's being input.

Is this expected behavior?

I would expect that if it doesn't have Protocol data as input, it won't output protocol data. Not while using the Process Engines to translate data anyway.

[fiverecords]

Hi @SirDur,
Thanks for the report — I think I've got a handle on what was happening. Working through your issue actually exposed a couple of related runtime-state bugs in the process engines, all of which are fixed in the next release.
Root cause: when a process engine had received sACN input at any point during the session and then lost it (source disconnected, network changed, console went away), the engine correctly entered its configured failsafe mode and started emitting that failsafe output continuously. That part is intentional. The bug was what happened when you then edited the engine — changed the input VLAN, swapped the output, disabled and re-enabled — the engine quietly carried the previous failsafe state forward and kept emitting the same bytes (zeros in your case, since Zero failsafe was likely active when the input was missing) on the new outputs. The engine wasn't generating fresh data, it was replaying what it had cached from before the edit.
What's fixed:

The internal "this engine is in failsafe and these are the bytes it's holding" memory is now wiped on engine disable and on edits that materially change inputs or outputs while the engine is in data loss. Cosmetic edits (renaming an input, relabeling) don't trigger the wipe, so engines operating normally don't get interrupted.
A separate but related bug where switching failsafe mode away from Hold and back (Hold → Stop → Hold, Hold → Zero → Hold, etc.) made Hold re-emit the wrong frame is also fixed. Hold now reads from a dedicated buffer that can only ever contain real live frames.

To make this kind of state easier to see, I've also added two things to the UI:

A status badge on each engine row and in the editor dialog that shows whether the engine is currently outputting live data, the startup buffer, or sitting in failsafe — and which failsafe mode is active (Hold last frame / Output zeros / Output full / Output scene / Stop stream). So if an engine ever does start emitting unexpected data, the badge tells you why immediately instead of leaving you to guess.
A Reset State button (in the engine right-click menu, the group right-click menu, and the editor dialog) that wipes the runtime memory on demand. After a click the engine looks at its inputs right now: live input → resumes normal merge; no input + startup buffer enabled → emits the buffer; no input + no buffer → goes silent on the wire. Useful any time you want the engine to forget what it was doing and start over without disabling and re-enabling.

All of this lands in the next release. Thanks for taking the time to report it — without your description I probably wouldn't have caught the failsafe-mode-roundtrip variant either.

[SirDur]

I'm glad I could help. This software seems super useful and I don't want to poke holes in the development and motivation you have. I'd really like to use it, so I'm doing my best to report what I find. There are some features or UI things I'd like to see, but I don't want to submit too many "issues" and feel more like a problem than a help.

[fiverecords]

Hi @SirDur,

No worries at all — bug reports and feature requests are very welcome. They genuinely help DMXRouter improve, and the more you find the better. Keep them coming whenever you spot something or have an idea you'd like to see.

[fiverecords]

The V1.10.1 version is already released, try it when you can.