Opened 14 years ago

Closed 14 years ago

#743 closed patch (fixed)

Fix "program not found in PAT" problem.

Reported by: Stuart Auchterlonie Owned by: danielk
Priority: minor Milestone: 0.19
Component: mythtv Version: head
Severity: medium Keywords: PAT not found
Cc: Ticket locked: no

Description

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.

Attachments (9)

find-correct-pat.diff (1.6 KB) - added by Stuart Auchterlonie 14 years ago.
Patch to pickup correct PAT.
mpegstreamdata-cleanup.diff (2.7 KB) - added by Stuart Auchterlonie 14 years ago.
Consolidation of duplicate code.
find-correct-pat-in-400ms.diff (4.1 KB) - added by Stuart Auchterlonie 14 years ago.
Find correct PAT with time limit of 400ms.
Changeset8551-revert.diff (1.9 KB) - added by Stuart Auchterlonie 14 years ago.
Reverts Changeset 8511
mpegstreamdata-cleanup-v2.diff (3.2 KB) - added by Stuart Auchterlonie 14 years ago.
New mpegstreamdata cleanup
find-correct-pat-in-400ms-v2.diff (3.3 KB) - added by Stuart Auchterlonie 14 years ago.
New find correct PAT in 400ms
find-correct-pat-in-400ms-v3.diff (3.2 KB) - added by Stuart Auchterlonie 14 years ago.
v3 of find correct pat in 400ms
limit-pat-warnings.diff (2.6 KB) - added by Stuart Auchterlonie 14 years ago.
Patch to only print warning once.
stop-excess-pat-debug.diff (531 bytes) - added by Stuart Auchterlonie 14 years ago.
Only resent _invalid_pat_seen once a good PAT seen.

Download all attachments as: .zip

Change History (28)

Changed 14 years ago by Stuart Auchterlonie

Attachment: find-correct-pat.diff added

Patch to pickup correct PAT.

comment:1 Changed 14 years ago by danielk

Milestone: 0.19unknown

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.

comment:2 Changed 14 years ago by danielk

Milestone: unknown0.20
Resolution: invalid
Status: newclosed

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

Changed 14 years ago by Stuart Auchterlonie

Attachment: mpegstreamdata-cleanup.diff added

Consolidation of duplicate code.

Changed 14 years ago by Stuart Auchterlonie

Find correct PAT with time limit of 400ms.

comment:3 Changed 14 years ago by Stuart Auchterlonie

Milestone: 0.200.19
Resolution: invalid
Status: closedreopened

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.

comment:4 Changed 14 years ago by 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...

comment:5 Changed 14 years ago by danielk

Resolution: fixed
Status: reopenedclosed

(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.

comment:6 Changed 14 years ago by Stuart Auchterlonie

Resolution: fixed
Status: closedreopened

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

Changed 14 years ago by Stuart Auchterlonie

Attachment: Changeset8551-revert.diff added

Reverts Changeset 8511

Changed 14 years ago by Stuart Auchterlonie

New mpegstreamdata cleanup

Changed 14 years ago by Stuart Auchterlonie

New find correct PAT in 400ms

comment:7 Changed 14 years ago by 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.

comment:8 Changed 14 years ago by 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.

Changed 14 years ago by Stuart Auchterlonie

v3 of find correct pat in 400ms

comment:9 Changed 14 years ago by 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 :-)

comment:10 Changed 14 years ago by danielk

Resolution: fixed
Status: reopenedclosed

(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...

comment:11 Changed 14 years ago by Stuart Auchterlonie

Resolution: fixed
Status: closedreopened

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.

comment:12 Changed 14 years ago by danielk

Milestone: 0.190.20

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

Changed 14 years ago by Stuart Auchterlonie

Attachment: limit-pat-warnings.diff added

Patch to only print warning once.

comment:13 Changed 14 years ago by 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...

comment:14 Changed 14 years ago by danielk

Resolution: fixed
Status: reopenedclosed

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

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

comment:15 Changed 14 years ago by oa@…

Resolution: fixed
Status: closedreopened

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

Changed 14 years ago by Stuart Auchterlonie

Attachment: stop-excess-pat-debug.diff added

Only resent _invalid_pat_seen once a good PAT seen.

comment:16 Changed 14 years ago by 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...

comment:17 Changed 14 years ago by 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.

comment:18 Changed 14 years ago by Stuart Auchterlonie

Milestone: 0.200.19

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.

comment:19 Changed 14 years ago by danielk

Resolution: fixed
Status: reopenedclosed

(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.

Note: See TracTickets for help on using tickets.