--- title: SRT Target overflow disconnects Troubleshooting guide slug: troubleshooting/srt-target-overflow-disconnects-troubleshooting-guide docTags: createdAt: 2026-03-27T17:00:42.847Z --- # What is an SRT Target Overflow Disconnect? An SRT target overflow disconnect is a condition where a Zixi Broadcaster detect that an output buffer for an SRT pull target has exceeded its capacity, causing the broadcaster to terminate and immediately re-establish the connection. Overflow on an SRT output is distinct from a general network drop or timeout. The Broadcaster is actively cutting the connection in response to buffer pressure - the underlying transport path may be healthy. Because the broadcaster reconnects automatically and quickly, the events can be easy to overlook - the stream appears to recover on its own. In practice, each disconnect-reconnect cycle causes a brief output interruption, and if the underlying cause it not resolved, the disconnects may continue to recur, often at increasing frequency under sustained load or high-motion content. # Why SRT Targets Overflow and Disconnect Understanding which of the following causes applies is the first step in selecting the correct fix. :::Heading{depth="3" indent="1"} Encoder sending excessive UDP packets (Packet Flooding) ::: The most common cause of overflow on a Zixi Broadcaster is an encoder sending 1 MPEG-TS packet per UDP packet instead of the recommended 7. This results in a packet rate 7x higher than expected, which overwhelms the broadcaster's SRT output buffer regardless of the stream bitrate. *Expected vs. actual packet rate for a 27 Mbps stream\:* - *Expected\: 27,000,000 ÷ 8 ÷ 1316 ≈ 2,565 packets/sec* - *Flooding\: \~18,000 packets/sec (approx. 7× too high)* If the observed packet rate is significantly higher than the expected value packet flooding is the cause. :::hint{type="success"} Fix: Configure the encoder to send 7 MPEG-TS packets per UDP packet. This eliminates the packet flod and removes the overflow condition. ::: :::Heading{depth="3" indent="1"} Network Path Differences Causing Output Buffer Overflow ::: When some SRT targets on the same source are stable while others are not, the cause is typically a difference in the different network path to each destination. The SRT latency buffer must be sized to accommodate the Round Trip Time (RTT) of the specific path. A latency setting this is adequate for a low-RTT destination (eg. a nearby data centre) will be sufficient for a high-RTT destination (eg. a distant cloud region), causing buffer overflow on the longer path while the shorter path targets remain stable. Recommendation: set SRT latency to at least 3-4x the measured RTT to the destination. Too low a latency setting is a frequent cause of SRT overflow on long distance paths. :::Heading{depth="3" indent="1"} Broadcaster Migration - Host Configuration Differences ::: Overflow issues that occur immediately after migration to a new Broadcaster instance are often caused by differences in the host environment rather than the stream itself. The stream and network may be identical, but the new host might be less capable of handling the same load. Contributing factors include: - OS-level socket buffer sizes smaller than the previous host - NIC settings or driver configuration that limit throughput or increase latency - Firewall rules on the new host that asymmetrically rate-limit traffic to specific target destinations - Software version differences between old/new broadcaster :::Heading{depth="3" indent="1"} Encoder Bitrate Spikes Exceeding SRT Buffer Headroom ::: Even with correctly configured packet rates and adequate SRT headroom latency, a VBR encoder that produces large bitrate spikes (ie. scene changes, fast motion or cut heavy content) can momentarily exceed the SRT output buffer's capacity. The spike saturates the buffer faster than it can drain to the target destination - triggering an overflow disconnect. This cause is particularly common on long destination paths where the drain rate is constrained by the bandwidth or RTT. :::hint{type="success"} See [Encoder Bitrate Spike Troubleshooting Guide](docId:9ci3Oqw8sz_lqibokrQoO) for diagnosis and fixes specific to this cause. ::: :::Heading{depth="3" indent="1"} Insufficient max\_bitrate Configuration in Zixi ::: The *max\_bitrate* parameter on Zixi Broadcaster inputs and Failover Groups controls internal buffer allocation. If *max\_bitrate *is set correctly within the 1.5-2x the stream's bitrate recommended value, the allocated buffer has no headroom to absorb short bursts - including retransmission overhead, bitrate spikes or congestion. When the actual bitrate (incl. overhead) exceeds the allocated ceiling, overflow results. # How Overflow Disconnects cause Problems Downstream ### Stream Instability and Viewer Impact Each disconnect/reconnect causes a brief interruption in the output stream delivered to the SRT pull target. This will be viewed as a black screen, audio dropout or momentary freeze at the receiving end. Even if the reconnect is fast, the interruption is visible and disruptive for live content. ### Cascading Failures in redundant Architectures In Failover configurations where multiple SRT targets are receiving from the same source, an overflow condition on one target does not always stay isolated. The processing overhead generated by the repeat disconnect/reconnect cycles on affected targets can increase load on the Broadcaster, degrading performance for stable targets on the same instance. In high-density deployments, a single flooding encoder or misconfigured target can trigger overflow events across multiple unrelated streams on the same host. ### Masking of Upstream Issues Because the Broadcaster reconnects automatically and quickly, repeated overflow disconnects can mask a more serious upstream problem. If overflow is caused by encoder packet flooding, the actual stream quality issue (malformed TS packaging, excessive PID rate, or encoder misconfiguration) goes unaddressed while the symptom (brief drops) appears to self-resolve. Without checking the system log, the overflow trigger may never be identified. ### Impact During Broadcaster Migration Host configuration differences can cause overflow disconnects and incorrectly be attributed to the migration process itself. Underlying socket buffer or NIC configuration difference then persists and continue to cause overflows on the new host indefinitely. # What to check :::Heading{depth="3" indent="1"} Confirm overflow is the trigger ::: ### What to Check Before investigating possible causes, confirm that overflow is the actual reason for the disconnect rather than a network timeout, authentication failure, or unrelated error. ### How - Check the broadcaster system log around the disconnect timestamps. At the default logging level you will see the output being dropped for buffer pressure, look for a `on_distributor_sink_stuck` entry for the affected sink immediately before the reconnect. To see the raw per-packet overflow events (log lines containing `OnRealData OVERFLOW`), raise the broadcaster log level to debug, since those lines are logged at debug level and are not shown at info. - Confirm the reconnect occurs immediately - a brief disconnect followed by instant reconnect is characteristic of an overflow-triggered cut rather than a network timeout, which typically has a longer reconnect delay. - In ZEN Master, check the event log for the affected target and note the exact timestamps of disconnect events. Cross-reference these against the Broadcaster log to confirm overflow entries at the same timestamps. :::hint{type="success"} **Root cause confirmed if: ** Overflow event is logged immediately before each disconnect, and reconnect is near-instantaneous. ::: :::Heading{depth="3" indent="1"} Calculate and Compare Packet Rate ::: ### What to check Determine whether the encoder is flooding the Broadcaster with an excessive number of UDP packets. ### How On the encoder or using a stream analyzer, measure the actual UDP packet rate on the source stream. Then calculate the expected packet rate: :::hint{type="warning"} *Expected packet rate = Bitrate (bps) ÷ 8 ÷ 1316* *Example: 27 Mbps stream* *27,000,000 ÷ 8 ÷ 1316 = 2,565 packets/sec expected* *If observed rate is 7x higher (e.g. 18,000 packets/sec)* ::: You can also capture a short packet trace on the Broadcaster's inbound interface using tcpdump and count UDP packets per second from the encoder source IP to confirm: :::hint{type="warning"} *tcpdump -i \ -n udp src \ -c 10000 2>/dev/null | wc -l* ::: :::hint{type="success"} **Root cause: ** Observed packet rate is 7× higher than the calculated expected rate — encoder is sending 1 MPEG-TS packet per UDP packet. ::: Configure the encoder to encapsulate 7 MPEG-TS packets per UDP packet. This is a standard setting on most broadcast encoders and is the correct configuration for MPEG-TS over UDP/IP delivery to Zixi. Confirm the packet rate drops to expected levels after the change. :::Heading{depth="3" indent="1"} Compare Stable vs Affected Targets ::: ### What to check If some targets on the same source are stable while others are overflowing, the cause is a network path difference between destinations. ### How - Identify which targets on the same source are stable and which are overflowing. If stable targets route to one destination and affected targets route to another, proceed with path comparison. - Measure RTT to both destinations from the Broadcaster host and compare. A significantly higher RTT to the affected destination confirms the path is the differentiating factor. - Check the SRT latency setting on both sets of targets. If the affected targets have the same latency setting as the stable targets but a longer path RTT, the latency is insufficient. **Latency should be at least 3–4× the measured RTT to that specific destination.** - Check for any firewall rules, QoS policies, or routing differences that apply to the affected destination path but not the stable one. - If all targets on the source are affected, path difference is not the cause - proceed to Steps 4 and 5. :::hint{type="success"} **Root cause: ** SRT latency setting is insufficient for the RTT of the affected destination path. ::: Increase the SRT latency on the affected targets to at least 3–4× the measured RTT. For example, a path with 80ms RTT requires a minimum SRT latency of 320ms. Apply the change and monitor for recurrence. Do not apply the increased latency to stable targets on shorter paths - unnecessarily high latency increases buffer size and end-to-end delay without benefit. :::Heading{depth="3" indent="1"} Check SRT Latency Configuration ::: ### What to check Even when all targets appear to be on similar paths, an undersized SRT latency setting is a common and easily overlooked cause of overflow on any destination with non-trivial RTT. ### How - On the affected targets in Zixi Broadcaster, navigate to **Outputs -> \[Target] -> Edit** and review the SRT latency setting. - Measure the current RTT to the destination from the Broadcaster host using ping or mtr. Confirm the latency setting meets the **3–4× RTT** minimum. If the latency is set to a default value (commonly 120ms or 200ms) and the actual RTT is above 50ms, the buffer is likely undersized for the path. - Also check whether the latency setting on the receiving end (if it is a Zixi device or SRT-capable decoder) matches or is compatible with the Broadcaster's output latency setting. A mismatch can cause silent buffer underruns at the receiver that feed back as pressure on the Broadcaster output buffer. :::hint{type="success"} **Root cause: ** SRT latency set to a generic default that does not reflect the actual path RTT to the destination. ::: Increase SRT latency on the affected output to **4× RTT** as a conservative starting point. Monitor overflow events in the Broadcaster log after the change. Reduce incrementally if the overflow resolves and lower latency is desired, keeping 3× RTT as the minimum floor. :::Heading{depth="3" indent="1"} Check Max Bitrate ::: ### What to check Confirm that *max\_bitrate* on the affected input and Failover Group is set high enough to provide adequate buffer headroom for the stream's peak bitrate. ### How - In Zixi Broadcaster, navigate to **Inputs -> \[Stream] -> Edit** and check the *max\_bitrate* value. Also check *max\_bitrate* on the associated Failover Group if one is in use. - Compare *max\_bitrate* against the stream's observed peak bitrate from the ZEN Master bitrate graph or Broadcaster input statistics - not just the nominal average. If *max\_bitrate* is at or close to the average bitrate, the buffer has no headroom for retransmission overhead, bitrate spikes, or burst events. - The recommended value is **1.5–2× the highest expected peak bitrate**. Eg. For a 20 Mbps average stream that peaks at 30 Mbps, *max\_bitrate *should be set to at least 45–60 Mbps. :::hint{type="success"} **Root cause: ** max\_bitrate set incorrectly, leaving no internal buffer headroom for peak traffic. ::: Set *max\_bitrate* to 1.5–2× the highest expected peak bitrate on both the input and Failover Group. Restart the affected input after the change if required for the new setting to take effect. :::Heading{depth="3" indent="1"} Check for Host Level Issues After Migration ::: ### What to check If overflow appeared after migrating to a new Broadcaster host, compare the host environment against the previous instance to identify configuration differences that reduce the new host's ability to handle the same load. ### How SSH into the new Broadcaster host and check the following: OS socket buffer sizes: *sysctl net.core.rmem\_max* *sysctl net.core.wmem\_max* *# Compare against values from the previous host.* *# Low values (\< 8MB) can cause SRT buffer pressure under high-bitrate conditions.* ** *# To increase (non-persistent — test first):* *sysctl -w net.core.rmem\_max=16777216* *sysctl -w net.core.wmem\_max=16777216* ** *# To persist across reboots, add to /etc/sysctl.conf:* *# net.core.rmem\_max = 16777216* *# net.core.wmem\_max = 16777216* ** NIC settings and driver version: *ethtool -i \ # Check driver version* *ethtool -g \ # Check ring buffer sizes* *ethtool -S \ # Check for RX drops* *# Look for: rx\_dropped, rx\_queue\_0\_drops, nic\_rx\_dropped* *# Non-zero RX drops indicate packets being discarded at the NIC level.* ** Software version and firewall: •       Confirm the Broadcaster software version on the new host matches the previous host, or review the release notes for any SRT-related changes between versions. •       Check firewall rules on the new host for any asymmetric rate-limiting or egress rules that target specific destination IPs or ports and were not present on the previous host. :::hint{type="success"} **Root cause: ** New Broadcaster host has smaller socket buffers, different NIC configuration, or additional firewall rules compared to the previous host. ::: Align the new host's OS socket buffer sizes, NIC ring buffer settings, and firewall rules with the previous host configuration. If the Broadcaster software version differs, review the release notes for SRT changes and test after aligning the version. # Summary Decision Tree SRT target(s) disconnecting and reconnecting repeatedly Overflow event logged immediately before disconnect? -> NO -> Not an overflow disconnect. Check for network timeouts or auth issues. YES - Continue below Observed packet rate >> (Bitrate ÷ 8 ÷ 1316)? -> YES -> Encoder flooding BX with 1 MPEG-TS per UDP packet. **Fix:** configure encoder to send 7 MPEG-TS packets per UDP packet **(Step 2)** **** Some targets on same source stable; others overflowing? -> YES -> Network path difference between destinations. **Check:** RTT to each destination; SRT latency on affected targets. **Fix:** increase SRT latency to ≥4× RTT on affected targets **(Step 3).** **** Issue appeared after migrating to a new Broadcaster host? -> YES -> Host configuration difference. **Check:** OS socket buffers, NIC settings, firewall rules, software version. **Fix: **align new host config with previous host **(Step 6).** **** Max Bitrate set at or close to nominal average bitrate? -> YES -> Insufficient internal buffer headroom. **Fix:** set max\_bitrate to 1.5–2× highest expected peak bitrate **(Step 5).** Overflow only during high-motion content or scene changes? -> YES -> Encoder bitrate spike exceeding SRT buffer headroom **Fix: **see [Encoder Bitrate Spike Troubleshooting Guide](docId:9ci3Oqw8sz_lqibokrQoO) increase max\_bitrate and review encoder VBV/CBR settings. Cause unconfirmed after above steps? -> YES -> **Action:** enable debug-level logging on the affected broadcaster (the raw `OnRealData OVERFLOW` lines are logged at debug; info level only shows the `sink_stuck`/`disconnect` entries). Collect logs and packet capture, and open a support ticket with RTT data and overflow event timestamps. # Escalation Checklist If disconnects continue after applying the fixes above, escalate to Zixi Support with the following: | Item | Details / Location | | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Broadcaster version and OS | Shown in Broadcaster UI header or /etc/zixi/version | | Stream name and affected target name | Push/Pull, protocol, SRT mode (caller/listener) | | System log with overflow events visible | Broadcaster log set to debug level (to capture `OnRealData OVERFLOW` lines) covering the period of disconnects; note that info level shows only the `on_distributor_sink_stuck`/`disconnect` entries | | Measured RTT to affected and stable destinations | From the Broadcaster host using ping or mtr | | Encoder packet rate and MPEG-TS-per-UDP configuration | From stream analyser or tcpdump capture on the inbound interface | | SRT latency settings for affected vs. stable targets | From Outputs → \[Target] → Edit | | max\_bitrate configuration for the affected input and Failover Group | From Inputs → \[Stream] → Edit | | OS socket buffer sizes and NIC settings on Broadcaster host | sysctl net.core.rmem\_max / wmem\_max; ethtool -g and -S | | Packet capture on the Broadcaster's inbound interface | .pcap covering the overflow period (tcpdump on the interface) | | | |