Fix "program not found in PAT" problem.

[Stuart Auchterlonie]

I've made a patch to fix the problem where people were seeing "program not found in PAT" errors over time as the EIT scanner was doing it's work.

This was due to a race condition where occasionally a new channel had been changed to, but the next PAT to come through was from the old mplex (normally withing 20ms of the channel change). The correct PAT would come through within the next 200ms

Now we check to see if there is a desired program and if it exists in the PAT before we emit the signal to say the PAT has been updated. Also the single program PAT isn't created until we've verified that the program we want is in the PAT we have got.

[Stuart Auchterlonie]

Patch to pickup correct PAT.

[danielk]

Except for the UpdatePAT() only being sent when the program isn't set, this is technically correct. But it would disable some useful warnings in CreatePATSingleProgram().

Right now CreatePATSingleProgram() tells you if the desired program wasn't found, which is a telltale inidicator that you need to rescan your inputs. And, it tells you if there are no programs in the PAT, a telltale indicator of a broken transport to delete from your lineup.

A better solution might be to avoid processing stale data. I thought that closing and reopening the file descriptor for the DVR device would be enough, but perhaps we need to reset the device somehow in the DVBSignalMonitor?

Please reply in the mailing list.

[danielk]

stuarta, reopen this when you have a new patch as discussed in the mailing list.

[Stuart Auchterlonie]

Consolidation of duplicate code.

[Stuart Auchterlonie]

Find correct PAT with time limit of 400ms.

[Stuart Auchterlonie]

I've updated the patch to fix this problem.

It comes in two parts. The first mpegstreamdata-cleanup.diff consolidates the duplicate code paths in HandleTables?.

The second is the real fix for this problem. If we receive a PAT that is invalid (ie. doesn't contain required program) then we setup a timer with a 400ms timeout. As PATs are required to be transmitted every 100ms (ATSC) and 200ms (DVB) then the correct PAT should turn up within this time period.

If it does not turn up then the timer expires, and a warning message is printed out.

[danielk]

Can you do find-correct-pat-in-400ms.diff without requiring mpegstreamdata-cleanup.diff?

The mpegstreamdata-cleanup.diff adds a malloc each time through the loop when it isn't needed. mallocs are the largest portion of time taken by the CPU during recording already...

[danielk]

(In [8551]) Fixes #743.

This is a narrow fix for the reported problem. The problem is that some DVB drivers still don't change channels properly and send you data from the last transport after it has reported being safely tuned to a new transport. This causes MythTV to print out a warning.

This warning leads to lots of spurrious MythTV bug reports. To suppress these driver bug reports in the MythTV bug tracking system, this commit delays the warning for a little over one second, and if it sees that the data becomes valid for the current transport in that time, it suppresses the warning.

[Stuart Auchterlonie]

The latest change doesn't suppress the warning messages as anticipated. Updated patchs to follow.

[Stuart Auchterlonie]

Reverts Changeset 8511

[Stuart Auchterlonie]

New mpegstreamdata cleanup

[Stuart Auchterlonie]

New find correct PAT in 400ms

[Stuart Auchterlonie]

Updated patches attached to fix this problem

1. Changeset8511-revert.diff
2. mpegstreamdata-cleanup-v2.diff
3. find-correct-pat-in-400ms-v2.diff

1. reverts [8511]
2. splits common functionality out into new functions.
3. redoes the early find-correct-pat-in-400ms to work with new number 2.

[danielk]

(In [8588]) References #743.

Applies the first two of Stuart's patches, a [8551] revert, and the cleanup patch.

The last patch needs a small fix; I've e-mailed Stuart the details, but basically the patch adds a signal and slot, and we're trying to phase those out on the backend for stability reasons.

[Stuart Auchterlonie]

v3 of find correct pat in 400ms

[Stuart Auchterlonie]

I've added version 3 of the find correct pat in 400ms patch. This uses MythTimer? instead of QTimer, thus avoiding the signal and slot handling that we want to avoid.

Daniel, just noticed a typo in one of the VERBOSE prints. I can't spell Process in "PAT is missing program, setting timeout" Not worth redoing the patch just for that :-)

[danielk]

(In [8619]) Fixes #743, by applying slightly modified patch.

This is to cope with some wackyness some DVB cards exhibit. Basically, if stale data is seen we wait 400 ms before issuing a warning. If in that time we see good data we just the bad data.

The problem with the drivers is that they are missing some fences which became a requirement for DVB drivers about 6 months ago. If anyone recalls the tuning problems with DVB Events, these fences were meant to do away with that problem, but the implementation lags the spec a bit...

[Stuart Auchterlonie]

There are now a few channels in the UK which have a placeholder in the SDT, but aren't as yet transmitting, so they currently don't have any PMT information in the PAT.

This causes the debugging to be printed out every 400ms or so thus filling up the log file. I'll prepare a patch to fix this problem by making the debug printing only come out once.

[danielk]

Stuart, I'm moving this to 0.20... I don't want to risk introducing a bug so soon before release.

[Stuart Auchterlonie]

Patch to only print warning once.

[Stuart Auchterlonie]

Patch added to fix the problem.

Daniel, I'll leave it up to you if you want this in before 0.19 or not. It's fairly simple...

[danielk]

(In [8695]) Fix #743, by applying slightly modified patch.

I reworked the patch a bit so as to be even less invasive.

[oa@…]

Still get these with 8742:

2006-01-28 10:13:20.369 Desired program #353 not found in PAT.

Can Not create single program PAT.

2006-01-28 10:13:20.813 ProcessPAT: Program not found in PAT.

Rescan your transports.

2006-01-28 10:13:20.817 Program #353 not found in PAT! Program Association Table

PSIP prefix(0x0) tableID(0x0) length(53) extension(0x3001)

version(14) current(1) section(0) last_section(0)

tsid: 12289

programCount: 11

program number 0 has PID 0x 10 data 0x0 0x0 0x224 0x16 program number 113 has PID 0x 104 data 0x0 0x113 0x225 0x4 program number 241 has PID 0x 103 data 0x0 0x241 0x225 0x3 program number 417 has PID 0x 10a data 0x1 0x161 0x225 0x10 program number 433 has PID 0x 109 data 0x1 0x177 0x225 0x9 program number 449 has PID 0x 10b data 0x1 0x193 0x225 0x11 program number 465 has PID 0x 10e data 0x1 0x209 0x225 0x14 program number 817 has PID 0x 100 data 0x3 0x49 0x225 0x0 program number 1105 has PID 0x 10c data 0x4 0x81 0x225 0x12 program number 4449 has PID 0x 106 data 0x17 0x97 0x225 0x6 program number 4465 has PID 0x 107 data 0x17 0x113 0x225 0x7

[Stuart Auchterlonie]

Only resent _invalid_pat_seen once a good PAT seen.

[Stuart Auchterlonie]

Only reset _invalid_pat_seen once we see a valid PAT. (patch added)

Otherwise we would see a new invalid PAT, which would then reset the flag saying we'd printed out the message, which would then print out the message and round and round we go...

[oa@…]

Okay, with this patch I've got the message twice in three hours, five minutes apart. The spam is over :)

Regarding the message itself - if I interpret it correctly, the program # is referring to a serviceid in a multiplex. The errors I'm seeing are referring to two channels (401 and 353) that do not exist in the broadcast signal on a regular basis. In both cases the PAT dump lists the other channels on the same multiplex, so Myth has tuned to the right multiplex. However, I *never* access the channels in question, so it's a bit surprising that the error messages refer to them, especially using the phrase "desired program not found in PAT".

If I may suggest an improvement, right now there are three "lines" of message: one with the generic "rescan" message, one with the PAT dump, and one with the program ID referred to as "desired". It would be very helpful to a user if these messages were merged to one stating something like: "Program #401 (channel name) not found in PAT on multiplex xx where it used to exist. Multiplex contents may have changed, please rescan your transports.", and this was available through the frontend system information log entries instead of just in the log file.

[Stuart Auchterlonie]

Daniel, this patch fixes a problem that was introduced when the previous patch was rewritten before being committed. The previous checkin is effectively useless without this 1 liner.

[danielk]

(In [8788]) Fixes #743.

One line patch from Stuart Auchterlonie, for I problem I introduced when I cleaned up his last patch. Sorry about that Stuart, I should have sent it back to you for testing since I've never been able to reproduce this problem reliably.

This ticket is about a error message that can end up spamming the backend log when the EIT scanner tries to scan a channel that no exists, or when you have a broken DVB driver, or when you use a rotor with DVB-S and see other satellites in the sky transmitting on the same frequency, modulation and polarity as the channel you are trying to pick up.