Techrider.live

Dante Subscription Errors: Diagnose Routes in the Right Order

9 min read · Updated October 3, 2026 · system technicians, FOH and monitor engineers, AV network engineers, broadcast operators, production managers, venue technicians, integrators, and touring audio teams

Diagnose Dante subscription errors by status, device visibility, format, clock domain, flow capacity, locks, network health, and verified audio recovery.

TL;DR — A Dante subscription error identifies the layer that prevented or degraded a receiver-to-transmitter route; it does not justify rebuilding the whole network. Read the crosspoint tooltip and device status first, then verify device visibility, channel identity, sample format, clock domain, flow capacity, access locks, link health, and receiver latency in that order. Change one cause at a time, confirm real audio at the destination, and preserve the known configuration for rollback.

A subscription is a stored receiver-to-transmitter route

In Dante Controller, a subscription tells one receive channel which transmit channel to use. The routing matrix shows its current state at the crosspoint.

A green subscribed indication means the connection is established. An in-progress or pending indication may be temporary while devices build routes. Warning and error indications require inspection. Hovering the crosspoint exposes a tooltip with the receive channel, transmit channel, route type, and—when something is wrong—a more specific message.

StateOperational meaningFirst action
In progressThe route is being establishedWait briefly, then recheck status
SubscribedThe network route reports healthyVerify correct source and audible destination
Warning or unresolvedThe stored source is missing or the media path is impairedConfirm transmitter visibility and physical/network path
ErrorA compatibility, capacity, lock, or network condition blocked the routeRead the exact tooltip before changing anything
PendingA device is still processing a group of changesStop adding changes and let the device settle

The status can change after a successful setup if a transmitter disappears, a format changes, a flow limit is reached, or the network degrades.

Read evidence before recreating routes

Start with four pieces of evidence:

  1. the crosspoint tooltip for the failing receiver and transmitter;
  2. the Receive tab status for primary and secondary paths;
  3. Network Status for subscription, latency, packet, and bandwidth indicators;
  4. Events and logs around the time the fault began.

Save or export the known configuration before deleting routes. Recreating everything can erase the evidence, consume more flows, and make the original cause harder to isolate.

Also confirm that the route names refer to the intended signal. A healthy subscription to the wrong channel is still a failed show outcome. The Dante device and channel naming guide provides a recoverable identity model.

Diagnose the error by layer

1. Missing or unresolved transmitter

An unresolved subscription usually means the receiver remembers a transmitter or channel that is no longer visible. Check:

  • power and physical link at the transmitter;
  • correct primary or secondary port;
  • switch port and negotiated speed;
  • device name and channel name;
  • selected network interface on the Controller computer;
  • IP address, subnet, VLAN, and discovery scope;
  • whether a replacement device reused the approved identity.

Do not delete an unresolved route merely to remove the icon. If the original or correctly named spare returns, the stored subscription may recover as designed.

Use the Dante IP addressing guide when the device itself is missing from Controller.

2. Incorrect channel format

A route can fail when the transmitter and receiver do not support the same channel format. Sample rate is the common boundary, and pull-up or pull-down settings can place otherwise similar devices into different clock domains.

Inventory both endpoints before changing either one. Confirm the approved show format, protect destinations, apply changes in a controlled order, allow required reboots, and rebuild only the routes that the format change invalidated.

The Dante sample-rate mismatch guide covers this recovery path in detail.

3. Mismatched clock domains

A clock-domain message means the media endpoints do not share compatible timing. Check ordinary sample rate, pull-up or pull-down, PTP or RTP mode, external synchronization, and managed-domain settings.

Do not choose a Preferred Leader at random. First restore one compatible domain, then verify leader election, follower lock, mute behavior, and fallback. For native Dante timing, follow the Dante clock leader guide.

4. No more receive or transmit flows

Dante routes are carried in flows. One flow can carry several channels, so channel count and flow count are not the same resource.

“No Receive flows” means the receiving device cannot accept another flow. “No more flows (TX)” means the transmitter cannot create another required unicast flow. This often appears when channels are spread across many devices or one transmitter feeds many receivers.

Before changing the network:

  1. inspect the endpoint's supported and current flow use;
  2. remove genuinely obsolete subscriptions;
  3. group needed channels efficiently where the product permits;
  4. evaluate a deliberate multicast flow when many receivers need the same channels;
  5. test the resulting bandwidth and rollback behavior.

Do not create multicast merely to hide poor routing hygiene. The Dante unicast versus multicast guide explains the fanout tradeoff.

5. Locked or access-controlled device

A locked receiver may reject subscription changes. A locked transmitter can prevent new subscriptions or require authorized access. On managed networks, the operator may also lack permission for the domain or device.

Identify the system owner and approved credential path. Do not factory-reset, isolate, or clear a lock during production unless the responsible owner has authorized the recovery procedure and the impact is understood.

A transmit scheduler error can indicate that the requested latency and the actual link speed are incompatible. A slow or saturated link can also prevent a new flow or create packet and latency errors after a route appears.

Verify every endpoint and uplink speed. Check utilization, discarded packets, errors, queue counters, and QoS policy along the complete path. A cable fault may cause a gigabit-capable port to negotiate at 100 Mbps.

Use the Dante network switch requirements guide for switch acceptance and the Dante latency settings guide for receiver-buffer diagnosis.

A green subscription is not the end of the test

Controller reports the network relationship; it cannot prove every analog, console, DSP, amplifier, or loudspeaker boundary around it.

When the crosspoint is green but there is no audio, verify in signal-flow order:

BoundaryCheck
SourceThe intended signal exists and is not muted
Transmit channelCorrect device, socket, name, format, and meter
SubscriptionCorrect Tx-to-Rx identity and primary/secondary health
Receive channelMeter activity, gain, mute, patch, and processing
DestinationOutput routing, amplifier, loudspeaker, recorder, or broadcast path

Also inspect whether the source is silent, the channel order is wrong, a console soft patch changed, or the destination is muted. The soft patch versus physical patch guide helps separate network routing from console and cable maps.

Use a fixed recovery workflow

1. Protect the show

Mute or isolate sensitive destinations if the diagnosis could create noise. Save the configuration and capture the tooltip, device status, events, names, format, clock, and network state.

2. Scope the fault

Determine whether one channel, one device pair, one receiver, one transmitter, one switch segment, or the whole network is affected. Compare a working route that shares most of the same path.

3. Fix the earliest failed layer

Restore physical link and device visibility before editing subscriptions. Restore format and clock compatibility before changing flow design. Resolve ownership or locks before attempting repeated writes.

4. Change one thing

Make one controlled change and let devices settle. Re-read the tooltip and status. Avoid simultaneous renames, format changes, route rebuilds, and switch edits.

5. Verify identity and audio

Confirm the exact source reaches the exact receive channel and audible destination. Check primary and secondary paths separately where redundancy is used.

6. Test return and rollback

Reboot or disconnect the relevant component only within the approved test window. Confirm routes recover, logs are clean, and the saved baseline remains usable.

Document the subscription handoff

Record:

  • transmitter and receiver device names;
  • transmit and receive channel names and physical sockets;
  • native, multicast, or RTP route type;
  • primary and secondary subscription state;
  • sample rate, clock domain, and latency;
  • current and available flow capacity;
  • switch, VLAN, uplink, and multicast owner;
  • lock or managed-domain owner;
  • known tooltip messages and approved fixes;
  • baseline, test evidence, spare procedure, and rollback.

Keep sensitive credentials outside a public rider. The digital audio network tech rider guide provides the larger handoff structure.

Dante subscription troubleshooting checklist

  • The exact crosspoint tooltip and event time are captured.
  • The transmitter, receiver, names, sockets, and channels are correct.
  • Physical links, addresses, VLANs, and discovery are healthy.
  • Sample rate, pull-up or pull-down, and clock domain match.
  • Transmit and receive flow capacity remain available.
  • Device locks and managed permissions have an identified owner.
  • Link speed, utilization, QoS, latency, and packet errors are checked.
  • Correct audio, failure recovery, and rollback are verified.

Common mistakes

Deleting every failed route. This removes useful evidence and may destroy subscriptions intended to recover when a source returns.

Changing the clock leader first. Many failures are identity, format, flow, lock, or link problems. Read the specific status before altering timing.

Counting channels instead of flows. Endpoint flow limits depend on how routes are grouped across devices, not only on the number of channel labels.

Trusting a green tick without listening. The source may be wrong, silent, soft-patched elsewhere, or muted after the network receiver.

Fixing several layers at once. Simultaneous network, format, naming, and route changes make cause and rollback ambiguous.

FAQ

Why is my Dante subscription failing?

Common causes include a missing transmitter, incompatible channel format or clock domain, exhausted transmit or receive flows, a locked device, insufficient link capacity, or another network-path fault. Read the crosspoint tooltip first.

What does unresolved subscription mean in Dante?

It usually means the receiver remembers a transmitter or channel that is not currently visible or reachable. Check power, cabling, port mode, names, addressing, VLANs, interface selection, and discovery scope.

What does no more flows mean in Dante?

The transmitter or receiver has reached its media-flow capacity. Audit current subscriptions, remove obsolete routes, group channels efficiently, and consider a planned multicast flow when many receivers need the same source.

Why is a Dante route green but there is no audio?

The network subscription may be healthy while the source is silent, the wrong channel is routed, or the receiver's console, DSP, output, amplifier, or loudspeaker path is muted or mispatched. Verify signal flow end to end.

How do you troubleshoot Dante Controller errors?

Capture the tooltip and events, scope the affected devices, then check visibility, identity, format, clock, flows, locks, link health, and latency in order. Change one cause at a time and verify real audio plus recovery.

Turn error messages into a recovery map

Store the verified routes, identities, formats, flow budget, network path, error meanings, and rollback beside the show documentation. In Techrider.live, keep them with the same Rider as the stage plot and input list, invite the responsible engineer to edit it, then save and inspect history before sharing the current version.

Related guides