"Overflow" Error (Output)

error "offline overflow" error on an output stream issue a target reports an "overflow" error, often shown together with an offline status ("offline – overflow") when the output is dropped and reconnects each zixi output holds a fixed send queue of 10,000 packets for every packet received from the source, the broadcaster checks how full that queue is; if it is full, the packet is dropped and the output is flagged overflow if the queue stays full, the output is treated as "stuck" and disconnected with reason overflow, so its status goes offline the error clears automatically once the queue drains below half this error appears on the target, but the root cause is almost always upstream at the source the queue fills when data arrives from the source faster than the target link can send it out — typically because of source bitrate spikes/bursts, or a max bitrate configured far above the stream's real bitrate (for failover/merged inputs, the input itself can also raise overflow when its outputs report new overflows ) resolution on the source , set the max bitrate to roughly 1 5–2× the actual bitrate of the stream a max bitrate set well above the real rate allows bursts the target cannot drain in time; values outside this range can cause the stream to experience issues confirm the target's downstream network/link has enough sustained capacity for the stream's peak bitrate note — don't confuse with "max bitrate times latency too high" that is a separate error, raised at connection setup (not at runtime) when max bitrate × latency exceeds the internal buffer limit ( 524,288 packets) if you see that specific wording, reduce the max bitrate and/or the latency