DVB Errors & Troubleshooting

Work the priorities in order

A first-priority error makes everything below it unreliable. Chasing an EPG fault while the PAT is intermittent wastes the afternoon.

1. Scope and the framework

Transport stream faults are easy to observe and hard to prioritize. A monitoring probe can report twenty indicators at once, and without a hierarchy you end up investigating whichever one has the most alarming name.

ETSI TR 101 290, Measurement guidelines for DVB systems, solves this by grouping indicators into three priority levels. The current edition is V1.4.1 (2020-06), and its structure is the backbone of essentially every commercial TS analyzer on the market — which is why learning the indicator names pays off regardless of whose equipment you use.

Every threshold in this sheet is quoted from TR 101 290 V1.4.1 directly. Where the standard has revised a figure, that history is noted, because stale numbers circulate widely.

2. First priority — the errors that stop decoding

Six indicators, in the order the standard lists them. If any is present, fix it before looking at anything else.

2.1 TS_sync_loss — how sync is actually declared

Synchronization is the precondition for everything: until the demux knows where packets begin, no other measurement means anything. The standard is specific about the hysteresis, and it is worth knowing because it explains why a stream can look briefly unstable without alarming:

Those asymmetric thresholds are deliberate: acquisition should be confident, loss should be quick.

2.2 Sync_byte_error — and why 204 bytes appears

The indicator is set as soon as a correct 0x47 fails to appear after 188 or 204 bytes. The second figure surprises people who only know the 188-byte packet: 204 = 188 + 16, the sixteen bytes being Reed-Solomon parity added by the channel coding. Analyzers that sit before RS decoding see 204-byte packets, and a tool configured for the wrong packet length reports continuous sync errors on a perfectly healthy stream.

The standard also notes something practical: some encoders drive the sync byte flag on a parallel interface to control randomiser re-seeding and byte inversion without verifying the byte is actually a valid sync byte. Checking it yourself is therefore worthwhile rather than assumed.

2.3 PAT_error and PMT_error — the 0.5 second rule

Both the PAT and the PMTs it references must recur at least every 0.5 s. Miss that and a receiver tuning in has nothing to work from: without a PAT, as the standard puts it, the decoder can do nothing and no program is decodable; without a PMT, the corresponding program is not decodable.

Two subtleties are easy to miss. First, nothing other than a PAT should be present on PID 0x0000 — a stray table there is itself the error. Second, both indicators check that the scrambling control field is 00. Scrambled signalling is a fault, not a security feature: PSI must stay readable or nothing can be located.

2.4 Continuity_count_error

One indicator, three logically OR-ed preconditions: incorrect packet order, a packet occurring more than twice, and lost packets. The standard notes that test equipment is not required to distinguish them, since all three point at the same class of problem.

The “packet occurs more than twice” case is worth separating mentally from loss. Duplication is legal — a packet may be sent twice — but a third copy is symptomatic of something deeper upstream, and the standard suggests keeping it under observation rather than dismissing it.

2.5 PID_error

Checks that a stream actually exists for each PID that is referenced. This is the indicator that catches remultiplexing mistakes: a PMT that advertises an elementary stream which is no longer being carried. The user-specified period should not exceed 5 s for video or audio PIDs. Subtitles, data services and audio with an ISO 639 language descriptor of type greater than 0 are explicitly excluded from that 5 s limit, since legitimate gaps there can be much longer.

3. Second priority — continuous monitoring

The stream decodes. These indicators catch the faults that degrade it over time, and the PCR family is where most real trouble lives.

3.1 The PCR family, disentangled

Indicator 2.3 is a combination of the two more specific errors below it, kept in the document for consistency with existing implementations. For new work, use 2.3.a and 2.3.b — the standard says so explicitly. The distinction is diagnostically useful:

3.2 PTS_error

Presentation Time Stamps should occur at least every 700 ms. Two caveats from the standard: PTS are only accessible if the stream is not scrambled, and the 700 ms limit should not be applied to still pictures, where long gaps are entirely normal.

3.3 CAT_error and Transport_error

The CAT is how a receiver locates the EMM streams for its conditional-access system. Scrambled packets present with no CAT means the receiver cannot obtain management messages — the service is encrypted and unopenable. The inverse check also applies: only a CAT belongs on PID 0x0001.

Transport_error reflects the transport_error_indicator bit set by an upstream demodulator. The standard recommends a resettable counter alongside the boolean, and notes that when this fires, no further error indication should be derived from that packet — its contents are already known to be untrustworthy, so downstream indicators would be reporting noise.

4. Third priority — application dependent

Whether these matter depends on what you deliver. A redistribution operator forwarding a single service may legitimately ignore most of them; a platform providing an EPG cannot.

As with the PCR indicators, several third-priority entries have been split into more specific successors — NIT_error into 3.1.a and 3.1.b, SDT_error into 3.5.a and 3.5.b, EIT_error into 3.6.a, 3.6.b and 3.6.c. The originals remain only for compatibility with existing implementations; new work should use the specific ones.

Unreferenced_PID deserves attention because it is the counterpart to PID_error. PID_error catches a PMT promising a stream that is absent; Unreferenced_PID catches a stream present that no PMT claims. Both are remultiplexing artifacts, and together they bracket the most common class of mux misconfiguration.

5. table_id reference

Several indicators are defined in terms of table_id values rather than table names, so the mapping is needed to read them. These values come from the TR 101 290 preconditions above and ETSI EN 300 468.

6. A triage method that works

The priority levels are not just a taxonomy; used in order they are an efficient diagnostic procedure.

7. Three production failures where the RF was fine

The framework above tells you what to measure. What it cannot tell you is that some of the most expensive faults present as signal problems and are not. These three come from operating SAT>IP Servers Pro in production, and each one wasted real time before the cause was understood.

7.1 Continuity errors caused by monitoring the signal

Symptom: Continuity_count_error at a steady low rate. Signal strength normal, carrier locked, no Transport_error. Replacing cables and re-pointing the dish changes nothing.

Cause: polling the DVB frontend for signal statistics competes with the demux for driver attention, and on some hardware and driver combinations the polling itself induces the errors. The measurement was creating the fault it was measuring.

Remedy: SAT>IP Servers Pro exposes -M *:0-0, which disables frontend polling entirely and, as its documentation notes, “may solve CC errors with some hardware/drivers”. The trade is explicit — you lose live signal reporting and gain a clean stream.

7.2 Near-total T2-MI CRC failure on a perfect carrier

Symptom: a DVB-S2 multistream transponder carrying a T2-MI feed. RF immaculate. The inner DVB-T2 multiplex undecodable, with CRC failures approaching 100%. Every signal measurement says the problem is elsewhere; every structural measurement says the data is corrupt.

Cause: the demodulator’s hardware multistream-to-TS de-encapsulation drops packets for this bursty traffic pattern — typically around 9%. Losing 9% of an encapsulated stream destroys the inner CRCs while leaving the outer carrier metrics pristine.

Remedy: stop asking the hardware to de-encapsulate. On STiD135-based tuners with the raw-bbframe driver patch, bbframe=1 makes the demodulator emit raw DVB-S2 baseband frames, and SAT>IP Servers Pro reconstructs the outer transport stream losslessly in software before the T2-MI demux sees it. It sets a reserved DTV_STREAM_ID bit per tune, so the same card keeps serving conventional transponders concurrently.

This failure is undiagnosable without treating baseband frames, multistream input selection and T2-MI encapsulation as separate layers. Measured only at the priority-indicator level, it looks like data corruption with no source.

7.3 A monitoring fault mistaken for a stream fault

Symptom: SNR reported as 0 after a brief signal interruption, indefinitely, while the tuner stays locked and streaming continues normally. Signal strength reads correctly. Other software on the same hardware shows healthy figures.

Cause: the Linux DVB API calls used to read SNR can return 0 during a signal event, and without a recovery mechanism the value never gets re-read once conditions stabilize. The stream was never affected — only its telemetry.

Remedy: SAT>IP Servers Pro gained explicit signal-validation and re-read logic for exactly this. The wider lesson is worth stating plainly: verify that your monitoring is healthy before trusting what it reports about the stream. A stuck sensor and a real fault look identical on a dashboard.

8. Tooling

The indicator names are portable across analyzers, which is the practical benefit of the standard. For open tooling, TSDuck implements transport stream analysis, table extraction, continuity checking and PCR measurement, and its plugin model composes well with a live SAT>IP feed as input.

Because a SAT>IP tier delivers a standards-compliant stream over IP, the whole analysis chain runs against a network URL rather than requiring local DVB hardware. Requesting the complete multiplex — pids=all — gives an analyzer everything it needs, PSI/SI tables included; requesting a PID subset gives it only what you selected, which is fine for monitoring one service and useless for auditing table repetition rates.

9. Standards

10. Sources

[1] ETSI TR 101 290, “Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems,” etsi.org. Verified September 2026. Source for the three-tier priority classification, the first, second and third priority error lists, the 0.5 s PAT and PMT check interval, the 700 ms PTS interval, the 5 s presence window for referenced video and audio PIDs, the 0.5 s Unreferenced_PID window, the 2 s, 10 s and 30 s SI table windows, and the scrambling check carried inside PAT_error and PMT_error.

[2] ISO/IEC 13818-1, published jointly as ITU-T H.222.0, “Generic coding of moving pictures and associated audio information: Systems,” iso.org and itu.int. Verified September 2026. Source for the 100 ms maximum PCR interval, the ±500 ns PCR accuracy requirement, the 4-bit continuity_counter and its blindness to losses in multiples of 16, the transport_scrambling_control value of 00 required for signalling, PAT carriage on PID 0x0000, and the CAT to EMM relationship behind CAT_error.

[3] ETSI TS 101 154, “Specification for the use of Video and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream,” etsi.org, version history v1.5.1 (2004-05) through v1.7.1 (2005-06). Verified September 2026. Source for the withdrawn 40 ms PCR repetition figure and for the 100 ms maximum repetition interval recommended for PAT and PMT, which TR 101 290 relaxes to 0.5 s as sufficient for many applications. ETSIETSI

[4] ETSI EN 300 468, “Specification for Service Information (SI) in DVB systems,” etsi.org. Verified September 2026. Source for NIT on 0x0010, SDT on 0x0011, EIT on 0x0012 and TDT on 0x0014, and for the minimum repetition rates behind SDT_actual_error, EIT_actual_error, NIT_actual_error and TDT_error.

[5] ETSI EN 300 421 (DVB-S) and EN 300 744 (DVB-T), framing structure and channel coding, etsi.org. Verified September 2026. Source for the 204-byte packet as 188 bytes plus 16 Reed-Solomon parity bytes, and for the analyzer packet-length assumption that produces persistent sync errors on a healthy carrier.

[6] SAT>IP Protocol Specification version 1.2.2, satip.info, standardised as EN 50585, which specifies both the control protocol and the media transport for forwarding satellite-delivered signals to clients over IP. Verified September 2026. Source for the pids=all request used to obtain a full multiplex, and for the constraint that SI_repetition_error and Unreferenced_PID cannot be measured on a filtered stream. githubvde-verlag

[7] Satline.tv virtual SAT>IP server and dedicated DVB server documentation, satline.tv. Verified September 2026. Source for budgeting the whole transponder bitrate on a monitoring feed.