TR 101 290 explained: what Priority 1, 2 and 3 errors actually tell you
A practical reading of the DVB measurement guideline — which errors reach the viewer, which thresholds matter, and which ones you should never wire straight to an alarm.
Every broadcast operation has the same recurring argument: "It's fine on our side." The headend points at the network, the network points at the encoder, the platform points at the broadcaster. Ending that argument requires a shared vocabulary, and in the DVB world that vocabulary is ETSI TR 101 290.
One clarification first, because it trips people up: the TR stands for Technical Report. This is not a compliance standard you can be certified against — it is a measurement guideline. It doesn't tell you what your stream must be; it tells you how to measure it so that two parties looking at the same stream describe it the same way. That distinction matters more than it sounds.
The logic behind the three priorities
The genuinely clever part of the document is that it groups errors not by technical severity but by what the viewer experiences. The ordering answers three questions in sequence:
- Can the receiver decode this at all? No → Priority 1
- It decodes, but is picture or audio damaged? Yes → Priority 2
- Picture is fine, but are the surrounding services broken? → Priority 3
So "how many errors do we have" is the wrong question. The right one is at which priority.
Priority 1 — the stream either works or it doesn't
If something here fires, the viewer sees a black screen, a freeze, or "no signal". There is nothing to debate.
| Error | Meaning | What it looks like in the field |
|---|---|---|
TS_sync_loss | Several consecutive packets fail sync | The stream is simply gone |
Sync_byte_error | First byte of a packet isn't 0x47 | Corrupted transport, usually network or satellite |
PAT_error | Program Association Table missing or late | The receiver can't know which programmes exist → nothing tunes |
PMT_error | Program Map Table missing or late | Channel is listed but won't open |
PID_error | An expected PID hasn't appeared within a set period | Video without audio, or subtitles that never arrive |
Continuity_count_error | Packet counter skipped or repeated | Dropped frames, macroblocking, audio clicks |
The timing thresholds come from the document itself: PAT and PMT must repeat at least every
0.5 seconds. The window for PID_error is user-defined; 5 seconds is a reasonable starting point.
Priority 2 — the stream runs, but its quality is arguable
This is the grey zone, and it's where operations teams legitimately spend most of their time.
| Error | Meaning | Threshold |
|---|---|---|
Transport_error | The TEI bit is set: the transport layer is declaring this packet damaged | Must be 0 |
CRC_error | A table (PAT/PMT/CAT/SDT…) fails its checksum | Must be 0 |
PCR_repetition_error | Clock reference doesn't arrive often enough | ≤ 40 ms |
PCR_accuracy_error | Clock reference arrives but drifts too far | ±500 ns |
PCR_discontinuity_indicator_error | Unflagged jump in the clock | Jump > 100 ms |
PTS_error | Presentation timestamps too infrequent | ≤ 700 ms |
CAT_error | Conditional Access Table problem on a scrambled service | Mandatory when scrambled |
When you see Transport_error, don't start with the encoder. The TEI bit is normally set by
an upstream device or the network. That error means "this arrived damaged", not "I damaged it".
Priority 3 — the viewer doesn't see it, but the customer complains
Picture plays, audio plays, and the EPG is empty or the channel name is wrong.
| Error | Effect |
|---|---|
NIT_error | Network information broken; automatic channel scan produces wrong results |
SDT_error | Service name/type missing → "Unknown" in the channel list |
EIT_error | Electronic programme guide empty or incorrect |
TDT_error | Receiver clock wrong; scheduled recordings drift (threshold: ≤ 30 s) |
Unreferenced_PID | A PID no table declares; usually wasted bandwidth |
Skipping this group entirely is a common and often defensible choice. But if you deliver over
DVB-T or DVB-S, TDT_error and EIT_error turn into subscriber complaints directly.
The harder question: what should actually raise an alarm?
Reading the guideline is easy. Building an alarm set you can live with is not. A few things we learned writing our own rules:
Never put a bare threshold on continuity count errors. A rule like "CC error > 0 → alarm" gets your notifications muted on the first night. What carries meaning isn't a single error but the rate accumulated over a window. We handle this with a sliding window plus hysteresis: the alarm opens at one threshold and closes at a distinctly lower one. Without that gap, a stream sitting near the limit will open and close an alarm every minute.
A CC error is not automatically the encoder's fault. Over multicast UDP the large majority of continuity errors are network packet loss. The practical way to tell them apart is to measure the same stream from two places at once. If both points show the same discontinuity at the same moment, the source is broken; if only one does, the path to that point is broken. From a single vantage point this distinction is impossible — your measurement tells you that something is wrong, never where.
PCR_accuracy is the biggest false-positive generator in the set. A stream that has passed
through an IP network or a remux will routinely graze the ±500 ns boundary. Rather than alarming
on it alone, treat it as meaningful when it coincides with a corroborating symptom — a dropped
frame, a buffer event.
Priority 1 errors are instantaneous; Priority 2 errors are durational. One second of
TS_sync_loss is an incident. PCR_repetition_error is an incident when it persists, not when
it happens once.
Does TR 101 290 apply to HLS and DASH?
Frequently asked, frequently answered wrongly. The short answer: it depends on the container.
- If your segments are MPEG-TS (classic HLS with
.tssegments), TR 101 290 measurements apply to the segment payload. Continuity counters, PCR analysis, PAT/PMT checks all remain meaningful. - If your segments are fMP4/CMAF (modern HLS and most DASH), TR 101 290 does not apply. There is no transport stream there; PCR, PAT and PMT have no equivalent.
The CMAF-side equivalents are different measurements entirely: segment continuity, manifest consistency, timestamp gaps, download timing, and decode-based QoE such as freeze, black frame and silence detection. If a vendor tells you their CMAF monitoring is "TR 101 290 compliant", it is worth asking precisely what they mean.
In short
The value of TR 101 290 lies less in what it measures than in making both sides use the same
words. "The picture is bad" is an opinion. "Over the last 15 minutes, Continuity_count_error
rate reached 0.4% at three separate measurement points while PCR stayed within spec" is evidence.
Contract discussions, vendor escalations and SLA reports run on the second one.
If you're curious what these measurements look like on your own streams, we're happy to walk through a short demo against a real feed.