[mythtv] What is the best way to implement overlapping recordings on one channel?

Glenn Moloney glenn062 at optusnet.com.au
Thu Mar 31 10:09:05 UTC 2005


Hi All,

I have a "feature" (well - I call it a feature) I want to implement: 
   
      Allow overlapping recordings on one tuner.

I am interested in feedback on how best to implement this feacture - in
a manner acceptable to the mythtv powers that be.

I find that I need to allow at least 5 minutes (up to 15 for some
networks in Australia) of "overrecording" on each program. If I want to
record programs following each other on the same channel - I need to use
two tuners. I would rather not use two tuners for this job - at least
for the case where the same recording profile is used for both
recordings.

As I see it, there are two approaches:

1: The "high-level" approach: A "recording" may be fragmented across
several fragments of files on disk. This means little change to the
low-level recording code mythtv. Also permits constructing "virtual"
recordings from existing recordings (eg. highlights), etc...

2: The "low-level" approach: Allow the output from one tuner to be fed
into two files during the overlap period. One approach would be to
extend the RingBuffer class to allow two (or more) output files to be
attached to each ringbuffer. There will also be some fiddling in
tv_rec.h to "do the right thing" during the overlapping recordings, and
some changes to how we test if a channel is available for recording,
transferring ownership of the ringbuffer, etc...

3: Copy data from the end of the previous recording into the next
recording. In this case, we delay the start of the second recording, and
copy the data from end of the previous recording file into the new
recording file. Needs to happen seamlessly.

I am favouring Option 2 - and have started planning for it.

Obviously there is more to it than I describe here - but you get the
idea. The scheduler will need to recognise that these recordings are NOT
a conflict (given the first feature is working correctly).

Any suggestions or comments welcome.

cheers,
glenn.



More information about the mythtv-dev mailing list