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

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

    Date: Tue, 29 Nov 2005 18:01:40 -0500
    From: "Michael T. Dean" <mtdean at thirdcontact.com>

    Nope.  It's never worked the way you're theorizing.  There's something 
    more going on that you didn't notice.  Are you sure the Good Eats 
    episodes were back to back?

It would, however, be seriously cool if Myth could cope with this, 
and I have an algorithm below for how.

[One of my major annoyances with a single-tuner TiVo was trying to
simultaneously deal with imprecise start/stop station timings versus
back-to-back episodes; in general, if you don't want to lose the start
or end of something (and hence add pre/post-roll), a TiVo will miss
every other episode in a marathon, and so will a Myth.  And if you
eliminate the pre/post-rolls, you're still not guaranteed not to have
the first or last few seconds of an episode wind up in the wrong
actual file, -and- you'll lose a few seconds no matter what as it
(unnecessarily!) reinitializes the tuner.  The workaround there
required noticing the pattern before recording, and then manually
recording a giant block that spanned the entire time interval (and
had pre/post rolls at the ends).  This means you lose the per-episode
information -and- can't delete a single one, since it's one giant
block.]

But Myth -could- do better that this---though it might require taking
too large a pair of pliers to its inner architecture (I don't know
enough to be sure).  My proposed solution would be:
(a) Notice whenever a pair of recordings has a nonnegative temporal
    overlap (e.g., they butt up against each other, or they actually
    overlap each other---this overlap could be because of pre/post
    rolls, or because of manual programming of start/stop times).
    Whenever this happens, ensure that both recordings are forced to
    the same tuner, and -do not reinitialize it- at any time during
    the overlap.  You want this to be true even during a butt and not
    just an overlap, because you can lose many seconds while the tuner
    gets told to retune even the same channel (tuner lock, OSDs from
    some cable boxes, etc).  [Does Myth already have this do-not-retune
    optimization?  I'm wondering what happens if you have 2+ tuners fed
    from one cable box that requires an IR blaster; many boxes will
    display the channel number and/or pop up an OSD as it's "typed"
    and that would ruin any recording still in progress, even if the
    two tuners would otherwise handle the situation by each encoding
    during the overlap interval.  I don't have that sort of HW setup
    (yet) so I can't test it.]
(b) During the overlap interval, copy data from the tuner to two
    different files instead of just one (e.g., the files for the first
    and second recordings).  Yes, this doubles I/O to the disk for a
    few minutes, but disk I/O bandwidth is plentiful.  (And obviously,
    if we're doing software encoding, that happens upstream of this so
    it's only done once; all I'm talking about here is putting the
    bits in two places, possibly with any required header when the
    second file gets opened, and/or starting on the correct frame/
    format boundary, etc---but all this code must already exist.)
(c) Iterate:  consider each pair of recordings on the same channel
    until you come to a gap.  (This might just happen automatically
    without any explicit iteration, depending on how (a) is done.)
    This will consolidate any number of same-channel recordings.

This -seems- easy enough, but the devil is in the details:  getting the
overlap detection integrated probably has some picky corner cases, and
I don't know if the internal architecture is flexible enough to dump a
stream to two files simultaneously.  But they seem doable.

And this would make a reasonably common situation require -half- as
many tuners as it otherwise would, while leading to superior results.
(This really comes out if you're unlucky enough to want to record
-two- channels, each with back-to-back stuff; now you'd suddenly need
-four- tuners without this optimization.)

So it might be that a few dozen lines of code could save a bunch of
hardware.