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

[Steve Daniels]

> -----Original Message-----
> From: mythtv-users-bounces at mythtv.org [mailto:mythtv-users-
> bounces at mythtv.org] On Behalf Of Michael T. Dean
> Sent: 29 July 2006 07:36
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] is mythtv smart enough to do
> this(overlap/back-to-back) with recordings?
> 
> On 07/28/2006 08:17 PM, Steve Hodge wrote:
> > On 7/29/06, Michael T. Dean <mtdean at thirdcontact.com> wrote:
> >
> >> On 07/28/06 17:22, Steve Hodge wrote:
> >>
> >>> On 7/29/06, Michael T. Dean <mtdean at thirdcontact.com> wrote:
> >>>
> >>>> /me anxiously awaits the post from the guy coding it when he realizes
> >>>> that the perfect situation discussed here doesn't cover it all ( and
> >>>> that it's a much more complex issue, as discussed at
> >>>> http://www.gossamer-threads.com/lists/mythtv/users/215475#215475 )
> >>> I don't see the relevance of the objections you raised in that post.
> >>> Can you elaborate? We are talking about a single tuner writing all of
> >>> both recordings, not having one tuner start a recording and a second
> >>> tuner finish it. So the multiple backend scenario you mentioned
> >>> doesn't apply.
> >> So, as soon as you install a second capture card, all your overpadded
> >> recording rules begin to conflict because Myth's behavior /all of a
> >> sudden/ changes?
> > What's a second card got to do with it? I don't see what you're getting
> at.
> 
> Did you even read the post or just copy its link?  OK, I'll assume you
> read it, but I was not clear in presenting the ideas.  So, let me try
> again.
> 
> Your words: "We are talking about a single tuner writing all of both
> recordings, not having one tuner start a recording and a second tuner
> finish it."
> 
> 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.)
> 
> So, once someone installs a second capture card, we're not talking about
> a single tuner writing all of both recordings, anymore.  If the system
> includes one hardware encoder and one software encoder or one encoder
> (hardware or software) and one digital tuner (or, worse, one of all
> three), how can data from two different types of encoders get written to
> the same file?

This is where I'm confused.. Why are you trying to write data from two
different cards ( or in a bad situation two different types of encoders) to
the same file? What I was talking about in the thread your referencing to is
using one card and splitting that into two files.

I think I'm going to have to suffer another of your condescendingly toned
emails that attempts to explain your point..

> 
> 2 minutes of HDTV followed by a jarring switch to BTTV-captured software
> encoded SDTV?  Not even looking at the technical issues involved in the
> MPEG-2-encoded HDTV and RTJPEG- or MPEG-4-encoded SDTV, this doesn't
> seem like a good solution.  And, /if/ the cards are on different
> backends, it's even harder to find a workable solution.  (Note, though,
> that we /still/ have a problem if they're on the same backend.)
> 
> So, if we say, "Well, we'll just make it only work when /all/ capture
> cards are the same type /and/ on the same backend," that means that
> Myth's behavior changes when someone installs new capture cards.  So all
> the recording schedules they've set up with a one PVR-150 Myth system
> (schedules that include overzealous padding) work fine, but when the
> user adds her new HDTV card, she all of a sudden has /more/ conflicts
> and--by adding a new capture card--has reduced the number of shows she's
> able to record.
> 
> Anyway, I'm bowing out of this thread, now.  If my point still isn't
> clear, feel free to start writing the code and attempting to submit a
> patch for inclusion.  If you don't start to see the issues then, you
> won't ever see them (or, you're far more creative than I and have come
> up with an ingenious solution for them).
> 
> Regardless, it's not me you need to convince.  Bruce Markey and David
> Engel (and, of course, Isaac) are the ones who will likely make
> decisions about whether to commit this type of functionality.
> 
> Mike

A confused Steve Daniels

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.5/403 - Release Date: 28/07/2006