[mythtv-users] Why am I getting PosMapFromEnc warnings?

[f-myth-users at media.mit.edu]

I just noticed yesterday that I have been getting thousands of these
in my backend logs, spread out across the last several months:

  HandleGopStart: gopset not set, syncing positionMap
  PosMapFromEnc: Warning, tried to fetch PositionMap from Encoder but encoder returned framesWritten == 0
  Position map filled from DB to: 1019
  SyncPositionMap watchingrecording total: 1020 entries
  Stream initial keyframedist: 15.

Some of them seem benign, but at least one spate of them coincided
with severe corruption of the recorded stream (I got about 5 frames
out of maybe 30 seconds of the stream), so now I'm wondering what's
causing these and how many of my recordings might have corrupted
sections hiding in them.  (Rebuilding the positionmap with the
commflagger didn't help; it looks like data might just be missing
from the recorded bits.)

They typically come out in bursts a few seconds long, and even some of
the long bursts didn't corrupt the recording (for the 4 or 5 I was
able to spot-check), but given that I first noticed this -because- of
a corrupted recording, certainly they're not all so benign.  [And see
below; it's possible my spot-checks were of the wrong part of the stream.
Since a lot of this video is archived for potential viewing later as
part of some research, if things are getting routinely corrupted in
the middle of recordings, it's not clear I'd notice without extensive
watching, so I'd really like to nail this pronto.]

As far as I can tell, this isn't related to load; they are continuing
to occur even when the machine is idle and/or recording on only a
single tuner.  And while it's difficult to tell (oh how I -wish- Myth
recorded -which tuner- grabbed a stream in any easy way---though I
-do- have full, verbose backend logs backend logs dating back months,
so some simple way of finding this out from them might help), I
believe this -might- be happening on all tuners.  It also doesn't
seem related to which channel.

(Actually, the couple of times this has happened today, it looks
like it happened a minute or two -after- a recording finished!
I'll keep an eye on that and try to confirm it, but that's -really-
peculiar, since presumably we aren't handling GOPs or video at -all-
at that point---or might this be caused by the commflagger running?
I have it set to start running while the recording is in progress,
which typically means it starts a few minutes in and continues at
least a few minutes past the end [and more if multiple simultaneous
streams are being processed, of course].  If this is the commflagger
complaining, then my spot-checks are totally wrong, since I was
spot-checking the part of the recording that was being recorded
corresponding to the timestamp in the logfile---which would be
a few minutes wrong if the commflagger is doing this, since it
runs behind.)

So what's happening here?

P.S.  Configuration:  Athlon 2800+ with 5 PVR-250's in MBE and
a clone machine with one 350 as a combined FE/SBE, all running
0.18.1 under Ubuntu Breezy, recording directly off an RF cable
feed.