I really like the idea of one and two. I like the idea of one, just as I hope that soon LiveTV will be implemented like this so that it is a little more stable than the current ring buffer implementation. This will also allow you to change channels and be able to rewind to where you were watching a previous channel.
I think two is the best way of attacking this little problem though, even if feature one did get implemented. I think this would provide a much more stable way of being sure that you only delete the correct bits of recording when that time comes. Also, you are actually recording *two* shows so you should get two copies ;) I tell you what though, being a fellow Aussie (from BNE), if you get this implemented, let me know and I for one will buy you a carton of XXXX (as in Castelmeine (sp?) for the non-Aussies) or two or whatever your poison may be. I am tired of only being able to record one channel even though I have two tuners. Thanks mate, Dave On Thu, 31 Mar 2005 20:09:05 +1000, Glenn Moloney <[EMAIL PROTECTED]> wrote: > 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. > > > _______________________________________________ > mythtv-dev mailing list > mythtv-dev@mythtv.org > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev > > > -- GMAIL is 'da bomb baby....YEAH I have GMail invites, if you want one, email me direct. _______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
