NDI discovered devices
NDI discovered devices is the place you use when the question is simple and operational: what NDI sources can this engine actually see right now? In production, that matters before a show starts, when a subnet changes, when a camera disappears, or when a new source is expected to appear without manual setup.
This page is useful because teams usually do not want to manage NDI sources one by one. They want a fast answer to three practical questions: which devices are visible, which ones are still alive on the network, and which entries can be safely cleaned up when the environment changes.
Read this module as an availability and trust layer for NDI. If your operators need confidence that the engine still sees the right cameras, graphics machines, or remote NDI feeds, this is the section that supports that workflow.
Examples by preset
The practical shapes here are not transport presets but operator checks: a discovery-side sync, a normal list read, and a quick activity check when a source may have dropped off the network.
Discovery side sync
{
"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"
}
]
}Operator list read
{
"limit": 10,
"skip": 0,
"sort": {
"created": 1
},
"filter": {
"type": "DEVICE_TYPE_NDI"
}
}Availability check
{}Workflow examples
Confirm that expected NDI sources are still visible before going live
Use this module when the team needs a quick confidence check that the engine still sees the right NDI cameras, playback machines, or graphics outputs before the session starts.
- Why it helps: the operator can distinguish between a source that was once known to the system and a source that is actually visible now.
- Typical fit: pre-show checks, remote-guest readiness, and verifying that a camera or workstation came back after a reboot.
Use the activity signal when a source seems intermittent
When a source appears and disappears, the important question is not just whether the row exists, but whether the engine is still seeing recent discovery traffic from it.
- Why it helps: this makes it easier to separate naming mistakes from real network visibility problems.
- Operational fit: subnet changes, Wi-Fi-to-wired transitions, unstable discovery domains, and troubleshooting why one NDI source is missing while others are fine.
Clean up device inventory after a topology change
When a site retires old senders or renames devices, this module gives the team a controlled place to review and remove stale rows instead of carrying dead entries forever.
- Why it helps: the operator list stays trustworthy and easier to scan under pressure.
- Operational fit: venue resets, temporary event networks, lab environments, and migrations between discovery layouts.
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.