SRT Output Disconnect Troubleshooting Guide
SRT Output Disconnect Troubleshooting Guide
SRT output targets failing to reconnect automatically following failover events on Zixi Broadcaster
What Are SRT Output Disconnections?
SRT (Secure Reliable Transport) is a UDP-based streaming protocol that establishes persistent output connections between a Zixi Broadcaster and a downstream receiver. When a failover event occurs such as the destination IP changing due to network path switching, the Broadcaster must reinitiate the SRT handshake with the new endpoint.
An SRT output disconnect occurs when that connection drops and is not restored automatically. This can leave a stream offline until an engineer manually intervenes. The issue is distinct from typical network loss and is specific to how the Broadcaster handles socket reinitialisation after a destination IP transition.
Troubleshooting Workflow
Work through the following steps in order. Resolve at the earliest identified point of failure before proceeding to the next step.
Example:
A SRT output target has gone offline, after previously being healthy and the issue has occurred after a failover event at the destination. Restart attempts on the stream through the Broadcaster UI did not restore it.
Step 1. Confirm the stream is genuinely disconnected and identify the affected output
What to check:
Confirm which specific SRT output target is affected, which Broadcaster it's on, and verify the current status in both the Broadcaster UI and ZEN Master.
- In ZEN Master: Navigate to the affected channel or source and check the output status. Look for a red or disconnected indicator on the SRT output target.
- In Broadcaster UI: Go to Outputs -> [Stream Name] and check the Connection Status column. Note port number and destination IP currently configured.
- Check the Broadcaster event log: In Outputs -> [Stream] -> Log, look for disconnect events that match the time of the failover. Note any error codes or timeout messages.
- Check whether other SRT outputs on the same Broadcaster are healthy: If multiple outputs share the same process ID (PID), a restart of one may affect the others.
Root Cause: Confirmed SRT output is disconnected and did not reconnect after destination IP changed.
Next Steps: Proceed to Step 2 to attempt restoration before investigating underlying cause.
Step 2. Attempt stream restoration
What to check:
The correct method to restore an SRT output that has not auto-reconnected is a CLI port reset, not a UI Stop/Start. Using the UI Stop/Start alone will not reinitialise the underlying SRT socket.
- Do NOT use Broadcaster UI Stop/Start first: This does not fully reinitialise the SRT socket and will not restore the stream in this scenario.
- Perform a CLI port reset: SSH into the Broadcaster host and run the appropriate Broadcaster CLI command to reset the specific port used by the affected SRT output. This forces the socket to close and reopen, triggering a fresh SRT handshake.
- After the port reset, monitor the output status in the Broadcaster UI for 60–120 seconds. The stream should reconnect automatically once the SRT handshake completes with the destination.
- If the stream restores: Document the time of the reconnection and proceed to Step 3 to investigate the root cause and prevent recurrence.
- If the stream does not restore after CLI reset: Proceed to Step 4 - the issue may be on the destination side.
Root Cause: SRT socket was in a stale state that required a full port reset to clear.
Step 3. Check for shared PID across SRT streams
What to check:
A known configuration behavior can sometimes cause multiple SRT UDP streams to share the same process ID (PID). This prevents per stream resets via the CLI, as any CLI reset command affects all streams sharing that PID simultaneously.
How:
- SSH into the Broadcaster host and run: ps aux | grep zixi
- Identify the PIDs associated with SRT output processes. If multiple SRT streams share the same PID, per-stream CLI isolation is not possible.
- In the Broadcaster UI: Go to Outputs and note the ports used by each SRT stream. If all SRT outputs share the same port process, a reset of any one stream will affect all others.
Root Cause: Multiple SRT streams sharing a single PID, preventing granular per-stream resets.
Step 4. Investigate destination side failover behavior
What to check:
SRT disconnections that occur specifically during destination IP failover events may be caused by the way the downstream receiver handles the IP transition. If the receiver switches IPs without sending a proper SRT connection teardown, the Broadcaster may hold a stale socket reference and fail to initiate a new handshake.
- Confirm the exact sequence of events: did the destination IP change before or after the Broadcaster reported the disconnect?
- Review any available PCAP from the time of the incident: Look for whether the SRT handshake (SYN) was attempted after the IP change, and whether the destination responded. A failure at SYN indicates the destination is not reachable on the new IP, or the Broadcaster is still targeting the old IP.
- Check the SRT output target configuration in the Broadcaster: Go to Outputs -> [Stream] -> Edit. Confirm the destination IP and port are correct and match the expected post failover endpoint. If the Broadcaster is configured with a static IP and the destination IP changed, it will not reconnect automatically to the new address.
- Ask the customer whether the destination uses a DNS hostname or a static IP. If static, and the IP changes during failover, the Broadcaster output will need to be manually updated or reconfigured to use the new IP or a DNS-based hostname.
Root Cause: Broadcaster targeting stale/old destination IP after failover, or SRT handshake failing because destination is not ready on the new IP.
Next Steps: Update the SRT output target configuration to use the correct post failover IP or DNS hostname. Consider configuring a DNS-based target so that IP changes are resolved dynamically without Broadcaster reconfiguration.
Step 5. Review SRT reconnection timeout settings
The Broadcaster's SRT output reconnection timeout controls how long it will attempt to re-establish a connection before giving up. If this is set too short, the Broadcaster may abandon the reconnection attempt before the destination has completed its failover transition.
- In the Broadcaster UI: Go to Outputs -> [Stream] -> Edit and locate the Connection Timeout / Reconnect Interval settings for the SRT output.
- If the timeout is less than the time the destination requires to complete its failover (5–30 seconds depending on the setup) the Broadcaster will stop retrying before the destination is ready.
- Increase the reconnection timeout to allow the Broadcaster more time to re-establish the SRT handshake after a failover. A recommended starting value is at least 30–60 seconds.
- After adjusting, trigger a test failover if possible, and monitor whether the stream reconnects automatically within the extended timeout window.
Root Cause: SRT reconnection timeout too short for the destination's failover transition time, causing the Broadcaster to give up before the receiver is ready.
Troubleshooting Decision Tree
SRT output target disconnected following failover event
UI Stop/Start restored the stream? -> No -> Proceed to CLI port reset (Step 2)
CLI port reset restored the stream? -> No -> Check destination IP / PCAP (Step 4)
Multiple SRT streams sharing same PID? -> Yes -> plan coordinated reset, escalate for version upgrade (Step 3)
Destination IP changed during failover? -> Yes -> Update SRT output target to correct IP or DNS hostname (Step 4)
Reconnection timeout too short? -> Yes -> Increase timeout to 30–60s+ and retest (Step 5)
No clear cause found -> Capture PCAP during next failover event and escalate to Zixi Support with full details
Escalation Checklist
When escalating to Zixi Support, include as much of the following as possible:
- Broadcaster version and host OS (e.g. Windows Server 2022, Amazon Linux 2)
- Affected stream name and port, destination IP, and SRT latency setting
- Broadcaster event log covering the period of the disconnect, with timestamps
- Screenshot of output statistics before and after the failover event
- PCAP captured during a failover event (even a stable-period capture is useful for baseline comparison)
- Confirmation of whether multiple SRT streams share the same PID
- Description of the destination failover mechanism (e.g. auto-switchover, DNS change, manual IP update)
- SRT output target configuration settings (destination IP/hostname, port, latency, timeout)
- Notes on any recent changes to Broadcaster configuration, network, or destination infrastructure