NDI discovered devices

NDI discovered devices

Use this module to answer one production question quickly: which NDI sources can the engine see right now? That check matters before going live, after a sender reboot, after a subnet change, or whenever a camera or graphics machine is expected to appear without manual setup.

This is the NDI visibility layer. It helps operators separate three different states that are often confused under pressure: a source that is currently discoverable, a source that was seen earlier but may now be stale, and a source that should be removed from inventory because the environment changed.

What this module solves

• Shows the NDI senders the engine can discover on the network.
• Provides an activity signal when a source appears intermittent.
• Keeps the discovered-device list trustworthy by allowing stale cleanup.

How to use it operationally

1. List discovered devices and filter for NDI entries.
2. Check activity when a source seems to appear and disappear.
3. Remove stale rows after renames, retirements, or temporary event network changes.

If an expected source is missing here, troubleshoot discovery and network reachability before investigating downstream ingest workflows.

Discovery activity preview

getStat for discovered NDI devices is intentionally simple. The key runtime question is whether a row is currently discovered right now, not whether it once existed in inventory. That boolean is what helps operators separate a stale entry from a sender that is actually present on the network.

The preview below mirrors the same processData.discovered field documented for getStat. Use it as a quick reference when the team needs trust in the discovery layer before debugging routes, receivers, or player surfaces downstream.

Example tasks

Discovery sync payload

Use when a discovery process reports the current NDI senders visible to the engine.

{
  "devices": [
    {
      "ndi_name": "Studio Camera A",
      "url_address": "192.168.10.41:5960"
    },
    {
      "ndi_name": "Graphics Output B",
      "url_address": "192.168.10.52:5960"
    }
  ]
}

List and filter discovered devices

Use when operators need a quick inventory view of current NDI entries.

{
  "limit": 10,
  "skip": 0,
  "sort": {
    "created": 1
  },
  "filter": {
    "type": "DEVICE_TYPE_NDI"
  }
}

Activity check

Use when a device exists in inventory but may no longer be actively visible.

{}

Production workflows

Validate the show patch before going live

Compare the discovered list against the expected camera, playback, and graphics sources before the event starts. If a sender is missing at discovery level, the issue is usually upstream of any receiver configuration.

Troubleshoot an intermittent NDI source

When a source flaps in and out, check activity instead of relying only on the device row. This helps distinguish a real network or discovery problem from a naming mistake or an old entry that is no longer relevant.

Clean up after teardown or device renaming

Temporary event devices, lab systems, and renamed senders can leave stale rows behind. Remove them so the list stays accurate and operators can trust what they see during live operations.

Operator guidance

• Treat current activity as the best signal of whether a source is really available.
• Do not assume an old discovered row means the sender is still reachable.
• Keep the device list clean after topology changes so troubleshooting stays fast.