[mythtv-users] 1 tuner, overlap consecutive recordings on single channel

[Mark Staudinger]

This has been kicking around in my head for a while, and I've finally put my
finger on exactly what's occurring.  I only have 1 tuner (PVR-250), and I'm
running the latest 0.18-fixes (rev 8079).

My default settings (global start recording 12 seconds before, end recording
20 seconds late) work for most single recordings, but there's always the
exception here and there.  And the global modifiers are (I think) thrown out
the window on a transition from show to show when recording consecutive shows.
  This is currently cropping up on Scifi channel, where I'm recording several
episodes of Stargate SG1 that I haven't seen previously.  Since they often run
in mini-marathons, I wind up with the first episode truncated, and perhaps
5-10 seconds of the first episode in the second recording.  

This isn't the end of the world, but there is often a few seconds of missing
data when this happens.  

However, I remember seeing some episodes of a different show (Good Eats) that
consistently had the same (20 second) segment exist in both the end of the
first recording, and the beginning of the second.  This seemed heartening.

Looking at my recording settings, the only difference is that Stargate SG1 is
set to start/end "on time", while Good Eats is set to record 1 minute past the
end.  So I theorized that this behavior only affected consecutive recordings
on the same channel that also had a hard setting for extending the end time.

When testing this theory, I find that selecting the "add 1 minute to
recording" option will now cause conflicts, even when the same show is being
aired consecutively on the same channel.

Has this behavior changed?  Because what I was seeing seemed to be the ideal
behavior, IMO.  When recording consecutive shows with the same tuner, same
channel, same recording profile, allow the extra time specified in the global
setting to exist in both recordings.  I don't see anything relevant in the
change logs or the user/dev lists, although there have been discussions on how
to handle this situation.

Thanks,
Mark