--- title: CC Error Troubleshooting Guide slug: troubleshooting/cc-error-troubleshooting-guide createdAt: 2026-03-18T18:54:02.086Z --- **Continuity Counter (CC) errors detected on incoming streams within Zixi Broadcaster / ZEN Master** **What Are CC Errors?** The **Continuity Counter (CC)** is a 4-bit sequence number (0–15, wrapping) embedded in the header of every MPEG-2 Transport Stream (TS) packet, unique per PID. Each successive packet on the same PID must increment the counter by exactly 1. A **CC error** is triggered when that sequence breaks, which indicates one of the following: | **Condition** | **Meaning** | | ---------------------- | --------------------------------- | | Counter value skipped | One or more packets were **lost** | | Counter out of order | Packets were **reordered** | | Counter repeated twice | Packets were **duplicated** | CC errors are a symptom of a problem, not a root cause. The troubleshooting goal is always to identify *where* in the signal chain the break is occurring. ## Troubleshooting Workflow Work through the following steps in order, from source along the stream towards the target. Diagrams within ZEN Master can provide a visual overview of the workflow. Resolve at the earliest point of failure before proceeding. **Situation:** The target customer advises they are seeing cc errors. Check content analysis within ZEN Master, starting at the source. Within the histogram you observe cc errors. Compare the Network histogram to see if drops/spikes align with the same time stamps as the cc errors. ![Screenshot comparing cc errors with network](https://api.archbee.com/api/optimize/mzxtTQEvCNIdUNgF2kuwJ/fQM1WBmMTb0s3xobADEQp-20260318-190150.png "Screenshot comparing cc errors with network") The event log will have useful information relevant to the cc errors like a specific PID. ![Event log showing Continuity Count Errors](https://api.archbee.com/api/optimize/mzxtTQEvCNIdUNgF2kuwJ/JspYWFZKaG2Zu_qeLwf3D-20260318-190328.png "Event log showing Continuity Count Errors") ### Step 1. Confirm the CC errors are originating from the source **What to check:** Before assuming a network or Zixi issue, verify whether CC errors are present *before* the stream even reaches Zixi. **How:** - If you have access to the encoder or upstream device, capture a local TS (e.g. via loop output or direct ASI/IP tap) and analyze it with a tool such as TSReader, Wireshark (MPEG plugin), or VLC. - In ZEN Master, navigate to the affected input object and check the TR101 histogram under “History” - If CC errors are visible immediately in the analysis for this source with no matching network anomalies (drops or spikes), the source is the likely culprit. ::Image[]{src="https://api.archbee.com/api/optimize/mzxtTQEvCNIdUNgF2kuwJ/Dk22vJVyZ5k96P7kEX8Es-20260318-192153.png" size="60" width="1085" height="463" position="center" caption="CC errors on the Source Histogram" alt="CC errors on the Source Histogram" darkWidth="1085" darkHeight="463" showCaption="true"} - In Zixi Broadcaster, go to **Inputs → \[Select Stream] → Stream Analysis → CC Error Histogram** and note whether CC errors are present from the moment the stream connects or only appear intermittently. ![Stream analysis Icon](https://api.archbee.com/api/optimize/mzxtTQEvCNIdUNgF2kuwJ/NkRGWktCgNJxytnN8cknX-20260318-193233.png "Stream analysis Icon") ::Image[]{src="https://api.archbee.com/api/optimize/mzxtTQEvCNIdUNgF2kuwJ/Y9vKdRv4mztEeKcPdfM-G-20260318-192618.png" size="82" width="1328" height="835" position="center" caption="CC error statistics in Broadcaster" alt="CC error statistics in Broadcaster" darkWidth="1328" darkHeight="835" showCaption="true"} **Root Cause:** CC errors present at source before any Zixi processing. **Advice:** Escalate to the source provider encoder/mux operator team. The issue lies upstream of Zixi and must be resolved at the encoding device. Provide them with a TS capture or CC error count with timestamps as evidence. ### Step 2. Check encoder configuration **What to check:** Even if the source appears healthy, incorrect encoder settings can produce malformed TS output. **Check the following on the encoder:** - **Restart the encoder - **Even a correctly configured encoder can begin generating CC errors after running for an extended period without a restart. This is not a network or Zixi issue it is an internal encoder process failure. Common causes include: - Internal mux scheduler corruption - Memory leak in the encoder process - PRC Clock drift accumulation - Thread deadlock in the mux pipeline - PID Counter wraparound bug - **Bitrate stability** - Is the encoder configured for CBR (Constant Bit Rate)? VBR streams with aggressive rate changes can cause buffer overflows in downstream muxers, leading to dropped packets and CC errors. - **PCR interval** - PCR should be injected every 40 (DVB minimum) – 100ms (ATSC minimum) per PCR PID. Misconfigured PCR spacing causes downstream sync issues that can manifest alongside CC errors. - **Mux rate overhead** - Ensure the encoder's configured mux rate includes sufficient null packet stuffing. A mux rate too close to the active content bitrate leaves no headroom and causes packet drops under load. - **Multiple audio PIDs** - Streams with many audio PIDs (e.g. multilingual feeds) are more susceptible to mux scheduling issues. Confirm that all PIDs are being correctly scheduled by the encoder's internal muxer. - **Encoder firmware/software version** - Known bugs in specific encoder firmware versions from manufacturers such as Sencore, Ateme, Elemental, and others can generate CC errors. Check the manufacturer's release notes for TS-related fixes. Update the firmware for the device for testing. **How to identify an encoder process issue:** - CC errors are present on a direct tap of the encoder output (before any network or Zixi involvement). - CC errors affect only specific PIDs, particularly lower-activity ones. - The issue began gradually or suddenly after the encoder had been running for an extended period (days/weeks) without a restart. - A cold restart of the encoder (full power cycle or process restart) resolves the CC errors immediately and cleanly. - Errors reappear after the same approximate uptime interval, confirming a runtime degradation pattern. **Root Cause:** Encoder misconfiguration or firmware bug producing CC errors at output. **Next Steps:** Correct the encoder settings (CBR, PCR interval, mux rate) or update firmware. If the errors appeared after a long runtime, perform a full encoder restart and monitor whether CC errors clear. If they do and then recur after extended uptime, document the interval and raise a firmware bug report with the encoder manufacturer. Request a clean TS capture directly from the encoder output port to confirm before and after. ### Step 3. Investigate the network path **What to check:** CC errors introduced during transit indicate packet loss, reordering, or duplication on the network between the source and the Zixi Broadcaster input. **How:** - In ZEN Master, check the **Network Quality** graph for the affected stream — high packet loss percentages directly correlate with CC errors. ![Not recovered packet loss ](https://api.archbee.com/api/optimize/mzxtTQEvCNIdUNgF2kuwJ/SPZzEjh1-D-i-AkFSGI0--20260318-194244.png "Not recovered packet loss ") - In Zixi Broadcaster **Input Statistics **(select a stream in broadcaster and statistics will appear at the bottom of the Interface window) review: - **Packets Lost** - Any value above 0 that is not being recovered indicates network-level loss. - **ARQ/FEC Recovery Rate** - If recovery is failing to keep up, the network loss is exceeding what the Zixi protocol can correct. - **Jitter** - High or spiking jitter values suggest packet reordering or an unstable network path, both of which cause CC errors. ![Statistics showing Jitter, Packet Loss, FEC/ARQ](https://api.archbee.com/api/optimize/mzxtTQEvCNIdUNgF2kuwJ/hcQIhn2pULIujcOoDjaMo-20260318-194807.png "Statistics showing Jitter, Packet Loss, FEC/ARQ") - Run a parallel path test — if possible, send a test stream over a different network path and compare CC error rates. - For streams transiting the public internet, check whether the issue is ISP-specific or time-of-day related (indicating congestion on a shared path). **Root Cause:** Network packet loss, jitter, or reordering in transit. **Next steps:** - Increase the Zixi Latency Buffer on the input — a higher latency setting gives the ARQ/FEC mechanism more time to recover lost packets before they are passed downstream. (We recommend a minimum of at least 1000 ms.) - If packet loss is severe, engage the customer's network team or ISP to investigate the transport path. - For persistent public internet issues, we recommend the customer consider a more stable transport option (dedicated circuit, managed IP transit, or bonded links). ### Step 4. Check Zixi Broadcaster input buffer and latency settings **What to check:** If the network appears healthy but CC errors are still present on the Zixi input, the Broadcaster's buffer configuration may not be correctly matched to the network conditions. **How:** In Zixi Broadcaster, navigate to **Inputs → \[Stream] → Edit** and review: - **Latency** - This defines the size of the jitter buffer and recovery window. If latency is set too low for the RTT of the connection, packets that arrive slightly late will be discarded rather than recovered, generating CC errors downstream. - Recommended starting point: set latency to at least **2–3× the measured RTT** between source and Broadcaster. - **Max Bitrate** - Ensure this is set high enough to accommodate the source stream's peak bitrate including TS overhead. An undersized max bitrate cap will cause the stream to drop incoming packets. - **FEC / ARQ settings** - Verify that the error correction mode configured on the input matches what the sending encoder supports. A mismatch disables recovery silently. ::Image[]{src="https://api.archbee.com/api/optimize/mzxtTQEvCNIdUNgF2kuwJ/RFb6CqFyksT56t-6X7BUP-20260318-195400.png" size="94" width="1737" height="427" position="center" caption="Input settings showing latency and max bitrate" alt="Input settings showing latency and max bitrate" darkWidth="1737" darkHeight="427" showCaption="true"} **Root Cause:** Latency buffer too small for network conditions, or input misconfiguration. **Advice:** Increase the latency value on the input. A conservative approach is to double the current value, observe CC error rate, and adjust from there. ### Step 5. Check server resources on the Broadcaster host **What to check:** On high-density Broadcaster deployments, resource exhaustion on the host server can cause the Broadcaster process to drop packets internally, generating CC errors that are not network-related. **How:** SSH into the Broadcaster host and check: \# CPU usage top The %Cpu(s) line at the top shows the breakdown of CPU usage (user, system, idle, etc.) To see usage per CPU core, press the 1 key while top is running. **top -H -o %CPU -b n1>top\_cpu.txt** This command shows the CPU usage only and writes it to a text document. \# Network interface errors and drops ip -s link show \ Provides detailed statistics for all network interfaces, including dedicated counters for errors and dropped packets. Also check the Broadcaster host's NIC receive buffer drops: ethtool -S \ Look for fields with names like rx\_dropped, rx\_queue\_0\_drops, rx\_discards, nic\_rx\_dropped, or similar driver-dependent counters. Any non-zero RX drop values indicate that packets are being discarded at the NIC level before Zixi even processes them. **Root Cause:** Server CPU overload, memory pressure, or NIC buffer exhaustion causing internal packet drops. **Next Steps:** - Reduce the number of streams on the affected Broadcaster or redistribute load across multiple instances. - Increase NIC ring buffer size. To increase the Network Interface Card (NIC) ring buffer size in Linux and reduce packet drops, use ethtool -G \ rx \ tx \ to set both Receive (RX) and Transmit (TX) buffers, typically to a maximum of 4096 or 8192. Run ethtool -g \ to view current and maximum supported ring buffer sizes. - For AWS deployments, verify that the instance type is appropriately sized for the number of streams and bitrates. Consider Elastic Network Adapter (ENA) optimized instance types for high-throughput workloads. - If using DPDK, validate DPDK configuration is applied correctly for the interface and kernel version in use. ### Step 6. Examine the output path and downstream decoder **What to check:** If no CC errors are reported on the Zixi input but the downstream IRD, decoder, or monitoring tool is reporting them, the issue may be introduced during Zixi output processing or on the Network segment between the Broadcaster and the decoder. **How:** - In Broadcaster **Outputs**, check the output statistics for the affected stream — compare CC error counts on input vs output. - If transcoding is active on the stream, CC errors can be introduced if the transcoder is dropping frames under load. Disable transcoding temporarily to isolate and test. - Capture the TS at the Broadcaster's output IP (e.g. via Wireshark on the LAN) and verify CC integrity at that point before it reaches the decoder OR send a duplicate test stream to a test target and verify. - For IRDs (e.g. Synamedia, Ericsson), be aware that some devices report CC errors for packets with the discontinuity indicator set, which Zixi may legitimately insert during stream reconnects or failover events. Confirm whether the CC errors correlate with connection events. **Root Cause:** CC errors introduced at output stage (transcoding, output misconfiguration) or falsely reported by decoder. **Advice:** - If transcoding is the cause, review transcoder resource allocation and reduce transcoding load. - If errors correlate with reconnects, these are expected transient events. Advise the customer that their decoder should tolerate the discontinuity indicator per MPEG-2 TS specification. - If false positives from the decoder are suspected, cross-reference with a second analysis tool (TSReader, VLC) to confirm whether CC errors are genuinely present in the TS. ### Troubleshooting Decision Tree CC errors reported on stream Present at encoder output? **→** YES **→** Encoder issue (Step 2) Network packet loss / jitter? **→** YES **→** Network / Latency issue (Steps 3–4) Server resources exhausted? **→** YES **→** Host resource issue (Step 5) Errors only at output / decoder? **→** YES **→** Output / Decoder issue (Step 6) No clear cause found **→** Capture full TS at input and output and escalate to Zixi Support ### Escalation Checklist When escalating to Zixi Support, you **must** include as much as possible of the following so that the team may investigate the issue: - Broadcaster version and OS - Stream name and connection type (Push/Pull, protocol used) - CC error count over time (input and output statistics screenshot) with time stamps. - Zixi Broadcaster log covering the period of errors (/var/zixi/broadcaster/log/) - Network path description (public internet, dedicated circuit, AWS region, etc.) - Latency and FEC/ARQ settings on the affected input - TS capture at Broadcaster input (Wireshark .pcap or TSReader analysis if available) - Notes on any recent changes to encoder, network, or Broadcaster configuration