Opened 16 years ago

Closed 16 years ago

#264 closed defect (fixed)

PMT always on fails CRC check

Reported by: danielk Owned by: danielk
Priority: minor Milestone: unknown
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description (last modified by danielk)

This happens on at least one channel for Allan Stirling, and Gernot Pansy.

Maybe a hardware or driver problem. But if there isn't a fix for that we could exempt this hardware from the CRC check on PMT's.

I need the startup output of "mythbackend -v channel" with the latest SVN from both Allan an Gernot to determine which devices to put on the list of devices for which we should verify the CRC of PMT.

Attachments (2)

PSIP_crc_error.txt (10.9 KB) - added by anonymous 16 years ago.
crc-bug-workaround.patch (3.8 KB) - added by danielk 16 years ago.
Workaround patch, disables CRC checking for "VLSI VES1x93 DVB-S" and "Philips TDA10046H DVB-T"

Download all attachments as: .zip

Change History (5)

comment:1 Changed 16 years ago by danielk

Description: modified (diff)
Status: newassigned

Changed 16 years ago by anonymous

Attachment: PSIP_crc_error.txt added

comment:2 Changed 16 years ago by Allan

This is very odd. I'm _sure_ I only saw this failure on one of my cards (DVB#0 in this log) a few revisions ago.

See attachment for log (PSIP_crc_error.txt)

Changed 16 years ago by danielk

Attachment: crc-bug-workaround.patch added

Workaround patch, disables CRC checking for "VLSI VES1x93 DVB-S" and "Philips TDA10046H DVB-T"

comment:3 Changed 16 years ago by danielk

Resolution: fixed
Status: assignedclosed

(In [7169]) Fixes #264.

The "VLSI VES1x93 DVB-S" and "Philips TDA10046H DVB-T" DVB cards occasionaly munge the PMT. The PMT is still readable but the CRC check fails. This commit changes MythTV so that it does not do a CRC check on the PMT for these cards

I'm assuming these cards read the PMT and write it out again much as MythTV does (probably to support CA since this only happens on the PMT). But unfortunately they change something (presumably the padding) without recalculating the CRC. If this assumption is correct these cards presumably verify the original CRC before rewriting the PMT, so it is safe to not check the CRC.

If I'm incorrect and these cards don't check the CRC then this is still relatively safe since these packets had to get past the error correction layer and the odds that the relatively infrequent and small PMT's have enough bit flips to get past EC with errors is very low.

Note: See TracTickets for help on using tickets.