[mythtv-users] 0.22 Now and Next only instead of 8 day EPG, lot of CRC errors

[Andy Burns]

Just upgraded to 0.22 (backend on CentOS5, mysql on another CentOS5,
frontend on Fedora11)

I had a couple of minor snags on the way (qt44 seems to have
disappeared from atrpms so I found that elsewhere, utf8/latin1
problems with database but recreating/restoring DB as per wiki didn't
fix that, so I had to empty my 'people' table as it had some corrupt
looking rows).

I have deleted/recreated all sources/tuners and done a full channel
scan which went OK.

Previously using "EIT only" was working fine with 0.21 but with 0.22 I
only seem to be getting "Now and Next" programme information, rather
than the full 8 day EPG.

With verbose logging on the backend enabled I see lots of

2009-11-07 18:27:10.369 PESPacket: Failed CRC check 0x66182710 !=
0xc3bfa4b5 for StreamID = 0x70
2009-11-07 18:27:11.309 PESPacket: Failed CRC check 0x66182710 !=
0xc3bfa4b5 for StreamID = 0x70
2009-11-07 18:27:11.357 PESPacket: Failed CRC check 0x66182711 !=
0xc3bfa4b5 for StreamID = 0x70
2009-11-07 18:27:12.297 PESPacket: Failed CRC check 0x66182711 !=
0xc3bfa4b5 for StreamID = 0x70
2009-11-07 18:27:12.345 PESPacket: Failed CRC check 0x66182712 !=
0xc3bfa4b5 for StreamID = 0x70
2009-11-07 18:27:13.285 PESPacket: Failed CRC check 0x66182712 !=
0xc3bfa4b5 for StreamID = 0x70
2009-11-07 18:27:13.333 PESPacket: Failed CRC check 0x66182713 !=
0xc3bfa4b5 for StreamID = 0x70
2009-11-07 18:27:14.325 PESPacket: Failed CRC check 0x66182713 !=
0xc3bfa4b5 for StreamID = 0x70

Which I notice other people had several years ago.

What seems strange when looking at the source of logging in
mythtv/libs/libmythtv/mpeg/pespacket.cpp

        VERBOSE(VB_SIPARSER,
	                    QString("PESPacket: Failed CRC check 0x%1 != 0x%2 "
	                    "for StreamID = 0x%3")
	                    .arg(CRC(),0,16).arg(CalcCRC(),0,16).arg(StreamID(),0,16));

it seems the received value for CRC is increasing by 1 every other
packet (I'd expect them to be essentially random not monotonic) and
the calculated value of the CRC is the same every time (I'd expect
this to also be essentially random not constant).

So it seems likely to me that something has its offsets into the
TSPacket structure munged.

I see several other people on the list with EIT problems, thoughts anyone?