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

[Paul Wheeler]

On 7/26/06, Daniel Walton <dwalton at cisco.com> wrote:
> Let's say you have one capture card just to keep the example simple.  You have
> two shows you want to record that come on back to back on the same channel and
> you want to record an extra minute at the beginning and end of each show:
>
> Show 1 - 4:59-5:31 (originally 5:00-5:30)
> Show 2 - 5:29-6:01 (originally 5:30-6:00)
>
> At 5:29 why couldn't myth start writing the recorded content to the show 2 file
> in addition to writing it to the show 1 file?  It only has to write to two files
> at once for the next two minutes and that would resolve the conflict.  It seems
> like that would be easier than trying to keep just one copy of the 5:29-5:31
> content that you magically play as a part of Show 1 and Show 2.
I presume this isnt possible within the current framework(without
major rewrite) otherwise a very nice idea. Any views on devs on this
one?

Paul


>
> Daniel
>
> On Wed, 26 Jul 2006, Michael T. Dean wrote:
>
> > On 07/26/06 12:10, Peter Watkins wrote:
> >
> > >On Wed, Jul 26, 2006 at 11:43:51AM -0400, Michael T. Dean wrote:
> > >
> > >
> > >>On 07/26/06 10:31, George Nychis wrote:
> > >>
> > >>>I have 2 shows recording back to back...
> > >>>
> > >>>First show: 5:00pm-5:30pm
> > >>>Second show: 5:30pm-6:00pm
> > >>>
> > >>>Both shows are on the *same* channel.
> > >>>
> > >>>If I set the first show to end 1 minute late, and I have only 1 tuner,
> > >>>is mythtv smart enough to put the [overlapping] minute into both recordings?
> > >>>
> > >>Nope.
> > >>
> > ...
> >
> > >If Myth should expect the same data for both recordings (e.g., both are
> > >HDTV, or both use the same recording profile), then I think Myth ought to be
> > >smart enough to copy/splice the overlap video into both recordings and only use
> > >one tuner. At least for schedules that are driven by program guide data (vs.
> > >VCR-style hard-coded date/time schedules), this should work really well.
> > >
> >
> > OK.  So let's say I'm recording a high-priority (+99) movie from
> > 3:30-5:30.  From 5:00-5:30 and 5:30-6:00 are two episodes of a
> > medium-priority (+50) show.  Since the TV show often goes a few seconds
> > beyond the scheduled time, I set an end late of 1 minute on the TV
> > show's recording rule.  So, assuming these are the only shows I'm
> > recording during this time period and I have two capture cards, I would
> > have recordings as shown:
> >
> > Card 0 - Movie - 3:30-5:30
> > Card 1 - Show - 5:00-5:31
> > Card 0 - Show - 5:30-6:01
> >
> > Notice that the two episodes of my show are being recorded on different
> > capture cards.  So, you may ask, "Well, why isn't Myth smart enough to
> > record both episodes of the show on the same card?"  Well, Myth /always/
> > uses the preferred input for capturing--assuming if you record it, you
> > want it to be high quality.  If multiple shows are being recorded at the
> > same time, the highest priority show is recorded on the most-preferred
> > input.  If all your inputs have the same specified priority, the
> > lowest-numbered input wins the tie.  If we randomly shuffle around
> > capture cards, we might get the high-priority movie recorded on a BTTV
> > card and the episodes of a medium-priority show recorded on a
> > high-definition card.  Myth shouldn't be making this decision--the user
> > should do so by rearranging priorities (possibly with a recording
> > override for the show).
> >
> > So, as Peter suggested, why not /if/ the cards are identical (i.e. both
> > PVR-x50's) still record the overlap to both files even though it will be
> > on different cards?  OK, imagine now a system with 2 PVR-x50's and a
> > BTTV card.  Can you say, "Non-intuitive behavior that's hard for the
> > user to predict."
> >
> > Now, keeping all this in mind, let's say we have 2 PVR-x50's and a
> > distributed Myth system with 2 backends.  At this point, how would we
> > get the data from a capture card on one backend to the filesystem on the
> > other backend?  Even if both backends write to a common networked
> > filesystem, we still have to ensure one of them handles writing the file.
> >
> > This is /not/ the "principal of least surprise."  Imagine all the
> > questions we would see about why /sometimes/ (in the general sense
> > because no one has been able to determine the pattern from empirical
> > evidence) Myth records the overlap successfully, but sometimes it doesn't.
> >
> > Just because it /seems/ easy to do on a simple MythTV system, don't
> > forget that Myth supports many more configurations.
> >
> > Also, if I put a start early of 1 minute on my TV show's recording rule,
> > I have a conflict:
> >
> > Card 0 - Movie - 3:30-5:30
> > Card 1 - Show - 4:59-5:31
> > Conflict - Show - 5:29-6:01
> >
> > At this point, the /only/ things I can do are:
> >     - adjust my recording rules (i.e. with a recording override)
> >     - get more capture cards
> >
> > Which means, that for both situations (recording an overlap or
> > preventing conflicts due to overlaps), the /right/ solution is to add
> > more capture cards.
> >
> > Mike
> > _______________________________________________
> > mythtv-users mailing list
> > mythtv-users at mythtv.org
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
> >
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>