←Back
⚑ Quick Reference

DVB Errors & Troubleshooting

Transport stream error triage in one screen. The ETSI TR 101 290 priority levels, the thresholds worth memorizing, and the single question that separates a reception problem from a processing problem.

0.5 s
Max PAT / PMT interval
100 ms
Max PCR interval
Β±500 ns
PCR accuracy
700 ms
Max PTS interval

Work the priorities in order

πŸ”΄ 1st β€” de-codability

TS_sync_loss, Sync_byte_error, PAT_error, Continuity_count_error, PMT_error, PID_error.

If any of these fires, everything below it is unreliable. Fix here first.

🟠 2nd β€” continuous

Transport_error, CRC_error, PCR_repetition_error, PCR_discontinuity_indicator_error, PCR_accuracy_error, PTS_error, CAT_error.

It decodes, but something will become visible.

🟑 3rd β€” application

NIT, SDT, EIT, TDT, RST errors, SI_repetition_error, Buffer_error, Unreferenced_PID.

Real, rarely urgent. Depends what you deliver.

The one question that saves the most time: do the errors track RF conditions? If yes, it is reception. If the carrier is locked and clean and errors persist, it is processing β€” and no amount of dish work will help.

Thresholds cheat sheet

WhatLimitIndicator
PAT on PID 0x0000at least every 0.5 sPAT_error
PMT on its PAT-referenced PIDat least every 0.5 sPMT_error
PCR intervalmax 100 msPCR_repetition_error
PCR accuracyΒ±500 nsPCR_accuracy_error
PTS intervalmax 700 ms (not still pictures)PTS_error
Referenced video/audio PID presentwithin 5 sPID_error
PID referenced by a PMTwithin 0.5 sUnreferenced_PID
SDT actual on 0x0011within 2 sSDT_actual_error
EIT present/following on 0x0012within 2 sEIT_actual_error
NIT actual on 0x0010within 10 sNIT_actual_error
TDT on 0x0014within 30 sTDT_error
Forget the 40 ms PCR figure. It was removed from ETSI TS 101 154 in 2005. Only the 100 ms limit from ISO/IEC 13818-1 applies now. Plenty of forum advice is still two decades out of date on this.

Symptom β†’ likely cause

You seeLook at
Constant sync errors, healthy signalPacket length assumption. 204 = 188 + 16 Reed-Solomon parity bytes. An analyzer set to the wrong length reports sync errors forever.
Nothing decodes at allPAT_error. No PAT means no program is decodable, full stop.
One channel dead, others finePMT_error or PID_error for that service.
CC errors on every PIDUpstream β€” RF, demodulator, or the link. Nothing selective is happening.
CC errors on one PIDThe multiplexer, a filter, or your own processing chain.
CC errors, perfect RFSoftware or driver. Frontend signal polling can itself cause them.
Drifting lip sync, periodic stutterPCR. Distinguish repetition from discontinuity from accuracy β€” different causes, different fixes.
Encrypted and unopenableCAT_error. Scrambled packets present with no CAT means no EMM can be found.
Plays, but no channel nameSDT missing. Third priority β€” cosmetic, not fatal.
Plays, but no EPGEIT missing or outside its repetition limits.
Stream fine, dashboard says SNR 0Your monitoring, not your stream. Verify the sensor before trusting it.

Three traps worth knowing

1
Continuity counter cannot see multiples of 16
It is 4 bits

Lose exactly 16, 32 or 48 packets and the counter lands where it would have anyway. Cheap check, not a guarantee.

2
Scrambled PSI is a fault, not security
Both PAT_error and PMT_error check it

The scrambling control field must be 00 for signalling. If tables are scrambled, nothing can be located.

3
You cannot audit tables on a filtered stream
You removed the evidence

Measuring SI_repetition_error or Unreferenced_PID needs the full multiplex. Request pids=all for a monitoring feed and budget the whole transponder bitrate.

Read more

About the author

Gleb Sazanov

Project Leader

Gleb Sazanov is an accomplished Chief Technology Officer (CTO) with over 20 years of experience in software development, system architecture, and cloud-based solutions. As the CTO of SATLINE, a leading provider of virtual and colocation services tailored to SATCOM businesses, Gleb drives the company’s technological strategy, fostering innovation and efficiency in data center services. His expertise spans various domains, including DevOps, system scaling, and high-performance infrastructure management. With a deep passion for cutting-edge technologies, Gleb plays a pivotal role in shaping the future of the SATCOM industry.