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

[chris at cpr.homelinux.net]

On Sat, Jul 29, 2006 at 02:36:19AM -0400, Michael T. Dean wrote:
> Since you didn't understand my post (linked above), the Cliff's Notes 
> version is:  "Back-to-back recordings are not always captured using the 
> same capture card, to ensure the highest-priority shows get recorded on 
> the highest-quality capture cards."  (And we're not talking a small 
> percentage of the time, either--I would say bordering on 50% of the 
> time, at least, on my systems.)

Perhaps some fuzzy logic is required?  In the multi-processor 
programming world, for example, threads have a "processor affinity" 
which says that they would prefer to be run on a specific 
processor.  Any reasonable execution scheduler will consider the 
affinity when scheduling the thread but won't take it as gospel.  
Sometimes running on the non-preferred hardware is simply the right 
thing to do.  If users *need* to schedule specific shows for 
specific capture cards, then maybe that should be available as an 
override or as a component of the original recording rule.  Think 
of it as a hardware variant of the "reschedule higher priorities" 
option -- scheduling becomes a best-effort task that brings with it 
some risks.  Let the user decide whether it's better to have 
unresolved conflicts or recordings made on non-preferred tuners.

The other solution (again) is to record in fragments and then 
either stitch them together in post-processing or else have 
playback code that can sequence fragments without hiccups.  Yes, 
that means you actually have to export (transcode) shows if you 
want to watch them on a non-Myth system, but again I'd suggest that 
being able to record shows is more important than being able to 
bypass the export step.

I understand that there is an issue with remote back-ends, but we 
are talking about only a few minutes worth of data and computers 
that are generally on a high-speed wired network connection.  If 
you have enough bandwidth to watch TV on a remote frontend then you 
probably have enough to spool recorded data from a tuner on one 
backend into a recording file on a different backend.

As an almost related aside, it would be interesting to see how Myth 
behaves in an OpenMosix environment.

> how can data from two different types of encoders get written to 
> the same file?

Another way to phrase that question is: "if I knew that data could 
come from multiple tuners is there any way I could write a program 
that was able to transcode the data so it had a consistent format?"

The main argument against recording in fragments is that some 
people want to be able to copy a monolithic file to another machine 
for non-Myth playback and don't want to have to export the file 
first.  While I understand the convenience that offers *to those 
people*, I'm not very sympathetic.  Do you think the MySQL people 
seriously considered storing the SQL data in ASCII files so people 
could view it using vi?  The point is that from a purist 
perspective an application should try to maximize its own potential 
before giving up performance for the benefit of external (and often 
unrelated) applications.