[mythtv-users] ProcessPAT: Program not found in PAT. Desired program # not found in PAT

[faginbagin]

On 2/7/2016 1:20 AM, Jason Zarin wrote:
> On Thu, Feb 4, 2016 at 6:16 PM, Mark Perkins <perkins1724 at hotmail.com
> <mailto:perkins1724 at hotmail.com>> wrote:
>     > On 5 Feb 2016, at 8:14 am, Jason Zarin <jason at zarin.org <mailto:jason at zarin.org>> wrote:
>     >
>     >>
>     > Why would that only affect recordings from one particular channel? Recordings on other channels record perfectly.
>     >
>     >
>
>     My only suggestions would be fishing for more clues. What does
>     mediainfo report of the corrupt file?
>
>
> media info puts out same info as "proper" recording.
>
>     Do PBS recordings made in the middle of the night (or at a
>     completely different time to your normal PBS recordings) exhibit the
>     same issues?
>
>
> Yes
>
>     When you deleted capture cards / transports / etc did you select the
>     "on all hosts" option not just the "on this host" option?
>
>
> Originally did just on this host, but then did a "on all hosts" per your
> suggestion. I only have 1 backend, so not entirely sure what the
> difference would be. Also deleted video sources as well. No difference
> -- still exhibiting same recording issues.
>
>     Is EIT disabled every where?
>
>
> Yes
>
>     In the MythTV log what activities are happening just before the
>     glitch like transcoding, another recording starting on a different
>     tuner for example?
>
>
> Nothing
>
>     Was this a network tuner, is it possible something is trying to grab
>     the tuner away from MythTV?
>
>
> A network tuner, but nothing else trying to grab it.
>
>     No multirec set when it shouldn't be?
>
> multirec is set fine.
>
>     Can't say any of the above are greatly likely to be the culprit but
>     might help narrow it down.
>
>     ________________________________________
>
>
> Honestly, I'm at wit's end on this. It's not a hardware problem. It's
> not a signal quality problem--my hdhomerun is the only thing hooked up
> to the cable feed, and it's one meter from the verizon fios box and
> hooked up directly. There are no splitters or anything that could weaken
> the signal.
>
> Every other channel appears to work fine, even the other PBS channel
> that shares the same transport as the PBS channel that has the
> ProcessPAT problem.
>
> So I've just gone ahead and marked the working PBS channel with a higher
> recpriority and let it handle most of the recordings.
>
> At this point all I can do is assume it's something in the broadcast
> source that the mythtv backend just chokes on. Or something goofy with
> the hdhomerun driver in linux. Either way, there's nothing I can really
> do about it. Maybe try an antenna to see if it's a problem created by
> FIOS's rebroadcast on the cable system and not in the original FTA
> source, although if I was able to get a decent antenna signal in the
> first place, I would even be bothering with clearQAM through cable.
>
> This was *not* a problem recording the same channel on Windows. So it's
> clearly a linux or a mythtv issue.
>
> If anyone has insight or other ideas, please continue to post in this
> thread, but I've expended way more mental capital that I expected to on
> mythtv when I set it up in the first place. I guess I'll just let
> recpriority take control to minimize recording on the problematic station.
>
> Thanks

Is your backend and the HDHomeRun connected to the same ethernet switch? 
Are all switches gigabit switches or some mixture with 100 Mbit in the 
path? I had a problem with glitchy recordings when my backend and 
HDHomeRun were not on the same switch and one of the switches was a 100 
MBit switch. When I swapped that switch for a gigabit switch, it fixed 
the problem. The glitches appeared random at first, but they occurred 
when there was other network activity in the house.

Why it should happen on only one station, I don't know. Maybe your PBS 
station uses a higher bit stream rate than the other channels, so it 
puts more demand on the network?

If it's not the network, I would also check disk I/O as Hika suggested.

Helen