[mythtv-users] is mythtv smart enough to do this(overlap/back-to-back) with recordings?

[chris at cpr.homelinux.net]

On Sun, Jul 30, 2006 at 06:06:57PM +1200, Steve Hodge wrote:
> > Do you really want to record a movie on a
> > noisy SD cable feed so that an episode of "Family Guy" that just
> > *happens* to be adjacent to another high-priority show on the HD
> > tuner can take advantage of the shared padding?  Even if all three
> > shows were on the same tuner, what do you do at 1930?
> Yes, I'd rather have the default behaviour to be to record the movie
> on an SD feed rather than miss something else I've asked for. If I
> didn't like that outcome I'd still have the options of altering the
> padding so the same tuner can handle both or overriding one of the
> scheduled programs.

The flip side of that position is to say that the (current) correct 
method is to record important shows with high-quality tuners and 
omit garbage shows if they get in the way.  That's why they're a 
lower priority - so they'll get out of the way!  That way you would 
always have the option of using the override to force the 
low-priority show to take the high-quality tuner.

> > "It won't scale" *is* a fundamental objection if the goal is to
> > create an easily extendable and maintainable system.
> But you still haven't explained how it won't scale. All you've done is
> bought up a few cases that can be used to argue that maybe the
> scheduler won't do what the user might want, because of the priorities
> applied.

In the absence of overlap recordings, adding more tuners results in 
a simpler placement of shows and a tighter recording schedule.  If 
you have hard padding then placement is still easy but efficiency 
is reduced.  If you have soft padding then you get all the ease and 
efficiency but with some shows not being padded as requested.  None 
of those solutions requires rewriting the scheduler since priority 
is the only factor considered when placing the shows into the 
schedule.  When you have overlap recording then you are 
complicating the scheduler because it has conflicting requirements 
to satisfy when placing shows - it has to balance off the desire to 
record the maximum number of shows versus the desire to pad.  
Adding a 3rd or 4th tuner only makes things worse because the 
scheduler has to consider the placement of overlaps on more than 
one tuner.  It becomes a chess game, with more parts meaning more 
possible moves to consider.

That's not to say that recording the overlap is a bad idea when one 
comes along through pure chance.  It's just that recording overlaps 
as a matter of policy and scheduling to create overlaps where they 
didn't otherwise occur naturally is going to be a lot of work for 
minimal gain.  Taking advantage of overlaps that happen by chance 
is *still* going to represent an increase in program complexity and 
will therefore almost certainly introduce more bugs.

> > Using fragments is only complicated because people are used to the
> > concept of a recording as a monolithic block and therefore *think*
> > that other solutions are too complicated.
> Do you think that fragments are going to be less complex (or less
> intrusive, if you like) to implement than the "recording into two
> files at once" enhancement?

Had the system been designed to work with fragments from the 
beginning then recording overlaps would be a no-brainer, as would 
parallel post-processing, archiving 8Gb movies to 4Gb media, etc.  
It would open doors that are currently beyond reach (like migrating 
a show from one tuner to another in mid-recording or using two 
tuners to record the same show and then averaging out the sampling 
noise in post-processing to get a cleaner picture).  That's the 
point I've been trying to make: a good design is complex at the 
core but abstracts easily and extends cleanly; a poor design is 
simple at the core but requires complex code at higher layers to 
make it useful.  No matter how you write the program there *will* 
be complexity.  The question is where to put that complexity.  The 
reason Myth uses MySQL instead of flat files is because the people 
who wrote MySQL have already done the complex part.

> I think it's going to be difficult to coordinate the fragments. My own
> system, for example, has an tuner recording the output of a satellite
> box (for encrypted channels), and a DVB-S card that can receive a
> subset of the same group of channels. But the same channels on the two
> tuners are not perfectly synchronised. How do you propose to handle
> that seemlessly?

It depends on the context, but would essentially boil down to 
pattern-matching in the short-term and statistical analysis in the 
long-term.  Switching tuners in mid show would not be easy and 
wouldn't be the best solution, but at least fragments would make it 
*possible*.