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
- List discovered devices and filter for NDI entries.
- Check activity when a source seems to appear and disappear.
- 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.
See the kind of state getStat exposes for discovered NDI devices
NDI discovered devices do not report bitrate or frame cadence. Their runtime signal is simpler and just as useful: is the row currently discovered right now. That boolean is what helps teams separate a stale inventory entry from a source that is actually present on the network.
discovered count
Previewing the same runtime signal operators usually inspect first.
2
How many current rows look actively discoverable right now.
3
A stale row can still exist in inventory even when its discovery flag is no longer active.
trust check
This is the signal operators reach for before blaming receivers, routes, or naming mistakes.
1:55:30 AM
Use repeated polling to separate a briefly missing sender from a genuinely stale device row.
This preview derives a simple activity line from the same discovered boolean you poll from getStat. It is most useful when operators need a trust signal before troubleshooting downstream ingest or receive workflows.
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.
Use Get all discovered devices for the operator-facing list of NDI sources currently stored by the engine.
This is the main read path behind the dashboard page. The UI calls it with a device-type filter and refreshes the listing every five seconds so the stored discovery state keeps moving without a full page reload.
Optional page size for the device list.
Optional offset for paginated listing.
Optional sort descriptor. The UI uses { created: 1 }.
Operator-facing NDI list calls usually filter by type: DEVICE_TYPE_NDI.
The backend returns a bare array of stored discovered-device rows.
Timestamp of the last discovery-side refresh for this device.
Use Get discovered devices count to size pagination and to confirm how many NDI device rows are currently visible after filtering.
In the product UI, this count works together with the five-second listing refresh rather than acting as a standalone diagnostics endpoint.
Optional filter object. The UI typically scopes this to NDI devices.
Total number of discovered-device rows visible to the authenticated user.
Use Get discovered device by id when you need the full saved row for one discovered device.
This is useful when a list entry needs to be inspected in isolation or when another tool needs the stored ndi_name, url_address, and discovery timestamps for one source.
Identifier of the discovered-device row you want to inspect.
The saved NDI discovered-device row.
Use Get discovered devices activity when the question is not only “is this device known?” but “is this device still being discovered right now?”
Think of this as a short-lived “still visible” signal. It helps teams decide whether the source is truly present on the network now, not just remembered from earlier discovery.
This is the fast heartbeat path that complements the longer-lived device list.
Activity-only rows used by the dashboard heartbeat refresh.
Identifier of the discovered device that is still considered active.
Becomes true when the device was refreshed inside the last five-second window.
Use Update discovered device when the operator wants to adjust the human-facing name of an existing discovered row.
The backend update path is intentionally narrow. It does not rewrite the NDI identity itself. It mainly updates the display name while leaving the discovery-driven fields under the sync flow.
Identifier of the discovered-device row to update.
Updated display name for the stored row.
The backend returns the updated discovered-device row.
Use Remove discovered device to delete one stored NDI device row from the local catalog.
This is a cleanup action, not a permanent block. If the same NDI source becomes visible again later, it can reappear in the discovered-device inventory.
Identifier of the discovered-device row to remove.
Indicates that the row was removed successfully.
Use this sync ingress when an NDI discovery-side process needs to publish the current list of seen devices into Callaba Engine.
This method is different from the normal operator-facing CRUD pattern. It accepts an array of discovered devices and either updates their url_address and discovered_last_time or creates a new device row when the ndi_name has not been seen before.
The dashboard list page itself does not call this endpoint directly. It consumes the resulting device list later through getAll, getCount, and getStat.
Batch of discovered devices from the discovery-side process.
NDI name used as the identity key when inserting or refreshing the device row.
Current discovery-side URL or host address reported for the device.
The service returns a boolean success result for the sync batch.