Diagnose tally problems

Missing tally#

1. Open Routing → Tally / UMD → Active and confirm the expected port shows the expected Channel at all. If it doesn't, the problem is on the Provider side, not the Consumer.
2. Open the Provider and confirm it's enabled, its condition actually matches the current input state, and its Target Ports / Bundles resolve to the port you expect.
3. If the Provider's condition is Feedback, confirm the connection it watches is healthy: a degraded connection can silently stop reporting feedback with no error visible unless you check the connection's own status.
4. If the Provider's condition is TSL Server Input, confirm the TSL connection is a Server (Listen) connection actually receiving data: see Send or receive tally and labels over TSL/UMD.
5. If Active looks correct but nothing reaches the display, move to the Consumer: confirm its Watch Item, that its Tally Lookup's relation and filter actually select the Channel you expect, and that its Reaction targets the right TSL connection, address, and screen.

Stale tally#

1. Change the real input state again and confirm Active updates. If it doesn't move at all, suspect the connection's feedback subscription rather than the Provider's configuration.
2. Check the connection's own status and logs: a connection that's degraded or reconnecting can leave tally on its last known value with no error surfaced through the tally model itself.
3. If a Consumer's displayed result lags behind Active, confirm its relation actually follows the routing you expect: a Selected Watch Item lookup only ever shows its own port, so a route change elsewhere in the chain won't move it.

Duplicated or unexpectedly combined tally#

1. Open Active and check Responsible Providers for the port: more than one Provider contributing at once is expected behavior, not a fault, but it explains why a Channel stays active after only one condition clears. See Interpret Active Tally state.
2. If a Consumer shows more indications than intended, check its Tally Lookup's Filter Mode: a broader filter than intended picks up Channels you didn't mean to include.
3. If a single change updates more destinations than expected, check whether a Provider's subject uses Active Destinations or Active Sources expansion: that deliberately spreads tally to every fed destination or feeding source, not just the immediate port.

Incorrect or missing labels#

1. Confirm the Consumer's Label Lookup uses the relation you expect: the same Selected Watch Item / Active Source / Active Destination distinction that applies to tally also applies to labels, and a mismatch here is a common cause of a label that doesn't follow the route the way the tally does.
2. Check Label Target (Port or Bundle) and confirm it matches how the underlying resource is actually organized.
3. If a label looks generic or unexpected, check the label resolution's fallback order: Buttons falls back through configured label types when a specific one isn't set, so a missing custom label can surface a different label type than you expected rather than an empty result.

TSL connection problems#

Safe test-mode cleanup#

1. Open the Provider or Consumer with Test Mode on.
2. Turn Test Mode off.
3. Save.
4. Confirm on Active, or on the display itself, that the temporary state actually cleared.

If you get stuck#

Where to go next#

• Understand the Tally system, for the full Provider/Consumer model.
• Interpret Active Tally state, for reading what a given tally result actually means.