Opened 13 years ago
Closed 12 years ago
Last modified 12 years ago
#10495 closed Patch - Bug Fix (fixed)
fix "PESPacket: Failed CRC check 0xVARIABLE != 0xVARIABLE for StreamID = 0x8x"
| Reported by: | Owned by: | danielk | |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.27 |
| Component: | MythTV - ATSC | Version: | Master Head |
| Severity: | medium | Keywords: | |
| Cc: | Ticket locked: | no |
Description
commiting #10207 (or something along the lines) uncovered a bug in PSIPTable::HasCRC where for all table ids from 0x80 to 0xfe it returns true to support Dishnet's EPG. The table_ids for CA_message_sections, which don't seem to have CRC, are 0x80 to 0x8f.
Attachments (3)
Change History (16)
Changed 13 years ago by
| Attachment: | 0005-fix-Failed-CRC-check-0xVARIABLE-0xVARIABLE-for-Strea.patch added |
|---|
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
Changed 13 years ago by
| Attachment: | 0005-fix-Failed-CRC-check-0xVARIABLE-0xVARIABLE-for-Strea.2.patch added |
|---|
Updated patch, no CRC for Dishnet
Changed 13 years ago by
| Attachment: | 0006-crc32-of-nothing-is-0-not-1-just-a-guess-based-on-ob.patch added |
|---|
Fix 0 != 0xffffffff, I'm not sure which way around its actually right, but this way I don't get errors
comment:3 Changed 13 years ago by
I had the EIT scanner and some recordings run over night with the updated patch and got no more CRC errors on empty PAT/PMT sections.
comment:4 Changed 13 years ago by
| Owner: | set to danielk |
|---|---|
| Status: | new → accepted |
comment:6 Changed 13 years ago by
| Status: | accepted → infoneeded |
|---|
I'm wondering if you'd be interested coming up with a more global fix...
As I see it the problem is that some of the CRC checks really need to know the pid the table arrived on. And possibly they need to know if we're dealing with DVB, MPEG, ATSC, etc data. But PESPacket construction doesn't ensure that we'll always have a pid to lookup.
We should really create a SectionCommon? class from which PSIPTable and PESPacket inherit and which provides a factory method for creating Sections which always contain a TS header with a valid pid. This means we'll never get to take advantage of zero-copy for single TS tables, but that is of pretty much nil importance and compicates the code. i.e. get rid of all the current constructors for PESPacket/PSIPTable & get rid of the View() methods and just provide a factory which assembles and returns sections from TS packet[s].
comment:7 Changed 12 years ago by
I got this too, but have not dishnet. What shall i post to you to support the analysis?
comment:8 Changed 12 years ago by
| Component: | MythTV - General → MythTV - ATSC |
|---|
comment:9 Changed 12 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | infoneeded → closed |
comment:10 Changed 12 years ago by
| Milestone: | unknown → 0.27 |
|---|
I've been running with #10494 *and* #10495 over night and the CRC errors on ECM/EMM are gone.
Whats left in the log is:
notice that the same block (this and the next on) is reapeated over and over, so it seems to be a systematic error, like still calling the wrong HasCRC() in some places. (notice the missing message from mpegstreamdata.cpp)
need to investigate this some more. I have a vague recollection of reading something about 0 / -1 having a special meaning in some CRC cases in the DVB domain but don't remember where I read that at the moment.
thats the first repeat, it goes on like this for some time while the backend is actively scanning the EIT on cable but it stopped ~7 hours ago and the rest of the night there are almost exlusively 0x0 != 0xffffffff messages.