TR 101 290 Explained: What the Error Levels Actually Mean in Production

If you work in broadcast engineering, you've seen TR 101 290 referenced in every monitoring tool, every SLA document, and every tender specification. But what does it actually mean in practice? What should you act on immediately, and what can you safely ignore at 2am?

This article breaks down each priority level — not from the spec, but from what actually matters when you're running a live broadcast operation.

What Is TR 101 290?

TR 101 290 is a technical report published by ETSI (European Telecommunications Standards Institute) that defines measurement guidelines for DVB systems. It was originally written for DVB-S, DVB-C, and DVB-T transport streams carried over ASI, but its priority structure has become the de-facto standard for monitoring IP-based broadcast streams as well.

The report defines three priority levels of errors. Each level tells you something different about the health of your stream — and requires a different response.

Priority 1 — The Stream Is Broken

Priority 1 errors mean your stream is unwatchable right now. These are not warnings. These are emergencies.

TS sync loss

The decoder has lost synchronization with the transport stream. No sync = no picture. This is usually caused by signal loss, severe bit errors, or a failed encoder. If you see this, something in your chain has failed completely.

Sync byte error

The 0x47 sync byte that starts every 188-byte MPEG-TS packet is missing or corrupted. Similar consequence to sync loss.

PAT error

The Program Association Table is missing or not arriving within 500ms. Without PAT, a decoder cannot find any services in the multiplex. A stream with no PAT is effectively a black box to any receiver.

PMT error

The Program Map Table for a service is missing. Without PMT, the decoder doesn't know which PIDs carry audio, video, and data for that service. No PMT = no service.

PID error

A PID referenced in the PMT is not present in the stream.

Continuity count error

MPEG-TS packets carry a 4-bit continuity counter. If packets arrive out of sequence or are dropped, this counter breaks. At low rates this may cause brief glitches; at high rates it signals serious packet loss.

Action: P1 errors require immediate response. Your monitoring system should trigger an alarm the moment a P1 condition is detected. If you have an on-call engineer, this wakes them up.

Priority 2 — Something Is Wrong, Watch It

Priority 2 errors indicate conditions that will cause problems for viewers if left unaddressed, but may not cause immediate failure. They're your early warning system.

Transport error

The transport error indicator bit is set in the TS header. This means the packet was flagged as corrupt by the receiving device (typically a demodulator). Occasional transport errors in a satellite chain are normal. A sustained rate indicates a degrading signal.

CRC error

A PSI table (PAT, PMT, NIT, etc.) has a CRC mismatch. The table arrived, but its content is corrupted. Receivers may reject it or use a cached version.

PCR repetition error

Program Clock Reference packets are arriving too infrequently — the spec says max 100ms between PCRs for continuous streams. PCR drives the decoder clock; if it's late, you'll see buffer underruns and audio/video drift.

PCR discontinuity

The PCR value jumps unexpectedly. Common during channel changes, ad insertions, or encoder restarts. A single discontinuity on a live event is expected. Repeated discontinuities on a playout channel indicate a problem with your playout system or mux.

PTS error

The Presentation Timestamp is missing or late. This affects lip sync and can cause audio/video drift that builds up over time.

CAT error

If you're running an encrypted service, the Conditional Access Table is missing. Your subscribers can't decrypt.

Action: P2 errors warrant investigation within your operational window — typically the same shift. They don't require waking someone up at 3am, but they shouldn't sit unresolved for days.

Priority 3 — Informational and Compliance

Priority 3 covers SI/PSI table timing and repetition rates — things like NIT, SDT, and EIT arrival intervals. These matter for:

• EPG accuracy — If EIT (Event Information Table) is delayed or missing, your electronic programme guide goes blank on receivers.
• Regulatory compliance — Some broadcasters are contractually required to meet specific SI repetition rates.
• HbbTV/AIT — If you're running red-button applications, the AIT (Application Information Table) must arrive within spec.

P3 errors rarely cause immediate viewer impact, but they can cause gradual degradation — EPG data that's hours out of date, or HbbTV apps that fail to launch.

Action: Review P3 errors during regular maintenance windows. Set thresholds, not alarms.

The Practical Reality: What Engineers Actually Do

In a real broadcast operation, most teams:

1. Alert hard on all P1 errors — automated alarm, on-call notification, escalation if unresolved within 5 minutes
2. Log and trend P2 errors — alert if rate exceeds a threshold, or if a P2 condition persists for more than 10–15 minutes
3. Review P3 weekly — check compliance reports, especially around EPG and HbbTV

The mistake most operations make is treating all errors equally — either alarming on everything (alarm fatigue leads to ignored alerts) or ignoring everything except complete outages (P2 problems quietly accumulate until a P1 event hits).

TR 101 290 and IP/OTT Streams

The original TR 101 290 spec was written for traditional transport stream delivery. When you're monitoring HLS, DASH, or UDP/RTP IP streams, the same underlying MPEG-TS structure applies — but there's an additional layer:

• Packet loss / jitter — IP networks introduce packet loss and jitter that don't exist in ASI. A monitoring system for IP streams needs to track these at the network layer before the TS layer.
• Segment availability (HLS/DASH) — Are manifests and segments arriving on time? A missing segment is functionally equivalent to a P1 TS sync loss for an OTT viewer.
• RTP sequence errors — Similar to MPEG-TS continuity count errors, RTP sequence numbers let you detect dropped or reordered packets.

A monitoring system that only checks TR 101 290 priorities without IP-layer visibility will miss the most common failure modes in modern IP broadcast chains.

What to Look for in a Monitoring Tool

When evaluating stream monitoring tools, check that they:

• Report P1/P2/P3 errors separately with individual thresholds and alarm policies
• Support both ASI and IP input (UDP, RTP, HLS, SRT)
• Provide PCR jitter graphs, not just error counts — trends are as important as alerts
• Show continuity count error rates over time, not just current status
• Include a multiviewer so you can visually confirm what the meters are telling you

Summary

Priority	What It Means	Response
P1	Stream is broken now	Immediate — automated alarm + on-call
P2	Problem developing	Same shift — investigate and resolve
P3	Compliance / SI timing	Weekly review

TR 101 290 is a tool, not a guarantee. A stream can pass all P1 and P2 checks and still deliver a poor viewer experience if PCR jitter is high, if audio levels are wrong, or if subtitles are missing. Use it as your baseline — and build your monitoring stack around it, not just on top of it.