[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 02:47:07PM +1200, Steve Hodge wrote:
> But you're still getting more recordings that you can get from MythTV
> right now so the proposed implementation is still a clear improvement.
> Is Michael (or are you) suggesting that no improvement should be made
> unless if solves all cases perfectly?

I'm certainly not suggesting anything of the sort.  Just because a 
proposal solves a particular problem doesn't automatically mean 
it's an improvement over the status quo if it closes off an avenue 
of development, though.  If you do that often enough then the 
system reaches a point where the only way forward is with a blank 
sheet of paper.

Some hacks (such as storing two shows in a single file) introduce 
more fringe cases than they solve.  If those kinds of hacks are in 
fact neccessary then it usually means the requirements weren't 
adequately defined in the first place and the design is simplistic 
(as opposed to simple).

> Highest priority show gets scheduled first. It gets the highest
> priorty tuner. Any other lower priority adjacent shows on that channel
> also use that tuner.

What about when the shows having sequential priorities are not in 
sequential time-slots?  Imagine that the top priority show is 
channel 38 from 1700-1900 and it gets tuner #1.  The next highest 
priority is channel 51 from 1930-2200.  Since there's no conflict 
it also gets tuner #1.  Then somewhere far down the list you have 
an ultra-low-priotity show on channel 38 from 1900-1930.  If you 
have padding then something's gotta give.  How much of a disparity 
in priority can you tolerate when bumping the #2 show from the 
high-quality tuner?  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?

> >   The more constraints you put on a situation ("two
> > shows on the same channel on the same tuner") the less practical
> > the solution becomes.
> But it's still an improvement over current behaviour and it's not a
> complicated solution (unlike the proposal to record shows with
> different tuners, and combine them in post processing). I still don't
> see a fundamental objection, just repetition of "it won't scale"

"It won't scale" *is* a fundamental objection if the goal is to 
create an easily extendable and maintainable system.  A scalable 
solution eliminates the need to find more than one way to solve the 
same problem and, more importantly, to build code that can 
determine which solution to apply for any specific set of 
circumstances (which risks introducing fringe cases).  If you have 
a solid foundation then you don't have to worry that each new 
feature will cause massive breakage, which accelerates further 
development.

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.  There's no practical 
need to continue with that model if it's incapable of supporting 
the legitimate requirements of the system.  There is precident, 
incidentally -- DVD movies are composed of multiple VOB files which 
are simply video fragments that are streamed in sequence.

Consider this: if the system was working with fragments then you 
could be watching live TV and be migrated from one tuner to another 
and hardly even know it (the same way you don't notice when your 
DVD changes VOB files or switches to the second layer).  Tasks like 
transcoding or commercial detection could be performed in parallel 
using all available CPUs/cores (or even other computers) because 
there would be no contention over access to serialized data.