DVB Errors & Troubleshooting
The TR 101 290 Priority Framework, Applied

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.

• First priority — "necessary for de-codability (basic monitoring)". If one of these is firing, nothing downstream can be trusted.
• Second priority — "recommended for continuous or periodic monitoring". The stream decodes, but something is wrong that will eventually be visible.
• Third priority — "application dependant monitoring". Whether these matter depends on what you are delivering.

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:

• Five consecutive correct sync bytes are proposed as sufficient to acquire synchronization.
• Two or more consecutive corrupted sync bytes should indicate sync loss.

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:

• PCR_repetition_error means the PCRs are arriving too far apart. The decoder's clock recovery loop is being starved of references, so it jitters or drifts, and it may lose lock entirely.
• PCR_discontinuity_indicator_error means the clock jumped without being flagged. Discontinuities are legal — that is what the discontinuity indicator is for — but an unsignaled jump makes the receiver treat a legitimate splice as corruption.
• PCR_accuracy_error is the tight one at ±500 ns, chosen so a color subcarrier can be synthesized from the recovered clock. Note the standard's caveat: this test should only be performed on a constant-bitrate transport stream.

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.

• Confirm sync first. If TS_sync_loss or Sync_byte_error is firing, stop. Check packet length assumptions — 188 against 204 — before suspecting the signal.
• Then the tables that make the stream navigable. PAT_error and PMT_error at 0.5 s. If either is intermittent, every downstream indicator is unreliable and every EPG complaint is a symptom rather than a cause.
• Then continuity. Establish the scope before the cause: errors on every PID at once point upstream; errors on one PID point at the mux or your own chain.
• Then PCR. Distinguish repetition from discontinuity from accuracy. They have different causes and different fixes, which is exactly why the standard split them.
• Only then the SI layer. Missing NIT, SDT or EIT changes the user experience without preventing decoding, so it is real but rarely urgent.

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 and sources

• ETSI Standards portal — TR 101 290 and the DVB specification set
• TSDuck — open-source MPEG transport stream toolkit
• SATLINE.TV Virtual SAT>IP Servers

10. About the author