Backend Crashes When Recording From Mux A In The UK (Freeview / DVB-T)

[anonymous]

I am experiencing problems recording from Mux A in the UK (Freeview) using my PCI DVB-T cards (Lifeview FlyDVB-T) - channels include abc1, Five, Five US, Five Life etc even after the fix specified in ticket 2664 ​http://svn.mythtv.org/trac/ticket/2664 (opened this new ticket as unsure whether its a new/related problem or not).

My other multiplexes appear fine (left them recording for >2 hours) and I have tried using tzap to see if there is any obvious problems but according to the Wiki's tzap page it seems to be outputting perfectly fine SNR/BER and UNC values.

The backend is crashing without any obvious reason (even when trying -v all) apart from from the error line PESPacket: Failed CRC check 0x0 != 0xffffffff for StreamID = 0x0 is always present in the backend.log file just before the backend crashes. If there is one recording happening I get one occurrence or if like the sample log file below there were three recordings happening I get three occurrences in the log file.

It is *always* 0x0 != 0xffffffff and never any other more random/realistic values. The backend does not crash after a specific interval it can be after 10 minutes or after 45 minutes but generally always easily within 30 minutes.

I have tested using up to revision 13552 from the trunk (which I assume has fix from ticket 2664) - the error is the same. Please let me know if you require more details, more log file output or anything testing. It just does not seem to like the way Mux A is transmitted which is a pity as I really want to start using my HTPC.

2007-05-29 15:57:13.786 Writing PAT & PMT @221925916 + 212064 2007-05-29 15:57:14.050 Writing PAT & PMT @261301012 + 282752 2007-05-29 15:57:14.134 DVBRec(0): 34 PID filters open. 2007-05-29 15:57:14.136 Writing PAT & PMT @268713852 + 1625824 2007-05-29 15:57:14.881 DVBRec(2): 31 PID filters open. 2007-05-29 15:57:14.966 PESPacket: Failed CRC check 0x0 != 0xffffffff for StreamID = 0x0 2007-05-29 15:57:14.968 DVBRec(2): SetPAT(13120 on 0x13a) 2007-05-29 15:57:14.969 CreatePATSingleProgram() 2007-05-29 15:57:14.970 PAT in input stream 2007-05-29 15:57:14.973 PESPacket: Failed CRC check 0x0 != 0xffffffff for StreamID = 0x0 2007-05-29 15:57:14.973 PESPacket: Failed CRC check 0x0 != 0xffffffff for StreamID = 0x0 2007-05-29 15:57:14.990 DVBRec(0): SetPAT(12866 on 0x1c05) 2007-05-29 15:57:15.011 DVBRec(1): SetPAT(14208 on 0x1c0f) 2007-05-29 15:57:15.031 CreatePATSingleProgram() 2007-05-29 15:57:15.051 CreatePATSingleProgram() 2007-05-29 15:57:15.071 PAT in input stream 2007-05-29 15:57:15.094 PAT in input stream (backend.log file ends here)

[danielk]

Need a backtrace... reopen ticket when you have one. If you could also attach a full backend log from startup to the failure using "-v record,siparser,channel" this may be helpful. Thanks.

[anonymous]

Thanks for the quick reply.

I have attached a gdb.txt and the associated myth.log that you have requested to this ticket. I have cut out repeating lines in the middle of the myth.log file to keep the file size down - I still have the original if you need it.

At the end of the myth.log file there are three "PESPacket: Failed CRC check 0x0 != 0xffffffff for StreamID = 0x0" entries and the backend then crashes.

On this occassion it took about 15 minutes to crash but it can be sooner or later but on average I would say its around 20 minutes.

If you require any other logs or anything trying out let me know.

[danielk]

Debugging patch

[danielk]

Can you try the attached patch?

A long time ago it was reported to me that the cards with the "Philips TDA10046H DVB-T" frontend destroyed the CRC of their PMT tables and so we had to turn off error checking and risk crashes in order to support this card at all.

However, a similar report was also filed about "DST DVB-S" cards, which I've now tested myself and it does not exhibit the reported problem, at least with drivers produced in the last year. The attached patch turns off the "don't check and fly blindly" behavior in MythTV for all cards. If you can tune in channels at all with this patch applied, it will take me 5 minutes to commit a proper fix.

[otto at kolsi dot fi]

Replying to danielk:

The attached patch turns off the "don't check and fly blindly" behavior in MythTV for all cards. If you can tune in channels at all with this patch applied, it will take me 5 minutes to commit a proper fix.

I have a card (Technotrend DVB-T Budget T1500 + CAM) with that Philips frontend:

DVBChan(1): Using DVB card 1, with frontend 'Philips TDA10046H DVB-T'

I tried couple of recordings and LiveTV both with and without CAM and all seem to work with patch applied. This is in Finland with FC5 backend and kernel: 2.6.20-1.2320.fc5smp.

[anonymous]

Fantastic. Just a quick update to say that I have seen your update and I will look at this over the weekend to see if it solves my problem with Mux A.

[anonymous]

I got revision 14063 from SVN and applied the patch (even though it looked like the changes were already in this revision).

Its looking good. I have left it on a channel off Mux A that used to crash easily (usually within minutes) for two separate three hour sessions and the backend did not crash once.

Many, many thanks - I am really looking forward to the next release now.

[danielk]

(In [14082]) Fixes #3541. Restores CRC checking for data coming from a couple DVB cards.

Cards using the "DST DVB-S" and "Philips TDA10046H DVB-T" frontends were previously reported to have munged the PAT & PMT sections, resp. These have both been recently reported to work without this hack and since processing garbage data can cause many difficuties, this changeset removes the DVB CRC Bug hack for both these cards.