[mythtv] Error: Wrong PMT and Failed CRC check after UK freeview network changes

[Roger James]

Roger James wrote:
> After the recent DVB transmission network changes here if the north 
> west of England my rescanning of transports on mythtv 0.21 
> installation seemed to have worked OK (after a few hiccups involving 
> the the transport scan picking up frequencies from the main 
> transmitter not the relays out of the NIT). However after a while I 
> noticed that one channel was not picking  up EIT(EPG) information. 
> This channel was BBC2, serviceid 4287 on transportid 4168. Other 
> channels on the same transport appeared to getting updated guide data 
> fine.
>
> I turned on eit and siparser logging and noticed the following errors 
> being logged when I switched live tv to the BBC2 channel (which viewed 
> perfectly!).
>
> 2009-11-23 17:44:42.324 PESPacket: Failed CRC check 0x76174442 != 
> 0xc3bfa4b5 for StreamID = 0x70
> 2009-11-23 17:44:43.322 PESPacket: Failed CRC check 0x76174443 != 
> 0xc3bfa4b5 for StreamID = 0x70
> 2009-11-23 17:44:44.327 PESPacket: Failed CRC check 0x76174444 != 
> 0xc3bfa4b5 for StreamID = 0x70
> 2009-11-23 17:44:45.323 PESPacket: Failed CRC check 0x76174445 != 
> 0xc3bfa4b5 for StreamID = 0x70
> 2009-11-23 17:44:46.323 PESPacket: Failed CRC check 0x76174446 != 
> 0xc3bfa4b5 for StreamID = 0x70
> 2009-11-23 17:44:47.328 PESPacket: Failed CRC check 0x76174447 != 
> 0xc3bfa4b5 for StreamID = 0x70
> 2009-11-23 17:44:48.325 PESPacket: Failed CRC check 0x76174448 != 
> 0xc3bfa4b5 for StreamID = 0x70
> 2009-11-23 17:44:49.313 PESPacket: Failed CRC check 0x76174449 != 
> 0xc3bfa4b5 for StreamID = 0x70
> 2009-11-23 17:44:50.327 PESPacket: Failed CRC check 0x76174450 != 
> 0xc3bfa4b5 for StreamID = 0x70
> 2009-11-23 17:44:51.324 PESPacket: Failed CRC check 0x76174451 != 
> 0xc3bfa4b5 for StreamID = 0x70
> ...
> 2009-11-23 17:44:53.715 DTVSM(201) Error: Wrong PMT; pmt->pn(6016) 
> desired(4287)
> 2009-11-23 17:44:53.721 DTVSM(201) Error: Wrong PMT; pmt->pn(4544) 
> desired(4287)
> 2009-11-23 17:44:53.722 DTVSM(201) Error: Wrong PMT; pmt->pn(4288) 
> desired(4287)
> 2009-11-23 17:44:53.723 DTVSM(201) Error: Wrong PMT; pmt->pn(4608) 
> desired(4287)
> 2009-11-23 17:44:53.724 DTVSM(201) Error: Wrong PMT; pmt->pn(4672) 
> desired(4287)
> 2009-11-23 17:44:53.726 DTVSM(201) Error: Wrong PMT; pmt->pn(4352) 
> desired(4287)
> 2009-11-23 17:44:53.727 DTVSM(201) Error: Wrong PMT; pmt->pn(4736) 
> desired(4287)
> 2009-11-23 17:44:53.728 DTVSM(201) Error: Wrong PMT; pmt->pn(4168) 
> desired(4287)
>
> I then used dvbsnoop to look at the PAT and PMT. The PAT showed that 
> the PMT for 4287 was being transmitted on PID 200 and the snoop for 
> this PID produced a correctly formatted PMT with the correct program 
> number (4287).
>
> I then noticed that I never saw a PAT for the correct transport (4168) 
> being built, other numerous other ones were. My suspicion is that 
> somehow an old PAT is being used although a quick glance through the 
> database did not produce any obvious candidates for where it might be 
> stored.  So my first question is. Does myth cache PATs and if so 
> where? If it doesn't then how does it determine which PMT pids to look 
> at?
>
> Also I wonder if the CRC errors are something to do with this as they 
> occur immediately before the Wrong PMT errors are logged.
>
> I do not want to upgrade to 0.22 (it does not seem to be available on 
> debian.multimedia yet) before I have bottomed this out.
>
> Any ideas anyone?
>
> Thanks,
>
> Roger
After much logging and looking at the code and my database setup, I can 
only conclude that this is related to the CRC errors. I think the wrong 
PMT error is a red herring as I have not seen it again for a couple of 
days. However there a lots of CRC errors and service 4287 still does not 
get any EIT data. dvbsnoop does not report any crc errors. I have line 
of sight to the transmitter which is less than a mile away so 
transmission errors are unlikely.  The StreamID of 0x70 is not a valid 
PES stream ID as far I can see all valid ones should have the top bit 
(0x80) set and the received CRC increasing by one on each packet looks 
very suspicious. Googling for the Failed CRC error reveals a lot of 
cases where the stream ID of 0x70 is reported.

Once again has anyone got any thoughts on this?

Roger