Documentation
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.
- 2026-09-21 19:36
- 2026-09-24 14:11
- Max PAT / PMT interval0.5 s
- Max PCR interval100 ms
- PCR accuracy±500 ns
- Max PTS interval700 ms
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
| What | Limit | Indicator |
|---|---|---|
PAT on PID 0x0000 | at least every 0.5 s | PAT_error |
| PMT on its PAT-referenced PID | at least every 0.5 s | PMT_error |
| PCR interval | max 100 ms | PCR_repetition_error |
| PCR accuracy | ±500 ns | PCR_accuracy_error |
| PTS interval | max 700 ms (not still pictures) | PTS_error |
| Referenced video/audio PID present | within 5 s | PID_error |
| PID referenced by a PMT | within 0.5 s | Unreferenced_PID |
SDT actual on 0x0011 | within 2 s | SDT_actual_error |
EIT present/following on 0x0012 | within 2 s | EIT_actual_error |
NIT actual on 0x0010 | within 10 s | NIT_actual_error |
TDT on 0x0014 | within 30 s | TDT_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 see | Look at |
|---|---|
| Constant sync errors, healthy signal | Packet length assumption. 204 = 188 + 16 Reed-Solomon parity bytes. An analyzer set to the wrong length reports sync errors forever. |
| Nothing decodes at all | PAT_error. No PAT means no program is decodable, full stop. |
| One channel dead, others fine | PMT_error or PID_error for that service. |
| CC errors on every PID | Upstream — RF, demodulator, or the link. Nothing selective is happening. |
| CC errors on one PID | The multiplexer, a filter, or your own processing chain. |
| CC errors, perfect RF | Software or driver. Frontend signal polling can itself cause them. |
| Drifting lip sync, periodic stutter | PCR. Distinguish repetition from discontinuity from accuracy — different causes, different fixes. |
| Encrypted and unopenable | CAT_error. Scrambled packets present with no CAT means no EMM can be found. |
| Plays, but no channel name | SDT missing. Third priority — cosmetic, not fatal. |
| Plays, but no EPG | EIT missing or outside its repetition limits. |
| Stream fine, dashboard says SNR 0 | Your monitoring, not your stream. Verify the sensor before trusting it. |
Three traps worth knowing
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.
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.
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
Gleb Sazanov
Chief Technology Officer
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.