[mythtv] RFC on proposed scheduler patch re: hdtv dups

[David Shay]

On 7/31/07, Bruce Markey <bjm at lvcm.com> wrote:
> First, I am in favor of a per rule option to double record
> matching episodes.
>
> I chose to not suggest that you read over the HOWTO sections
> on scheduling because it may come off as RTFM. I know you are
> a bright guy and wrote the DataDirect code and hoped that you
> were aware of the HOWTO content when considering this but...
>
> http://www.mythtv.org/docs/mythtv-HOWTO-12.html pay particular
> attention to the "Scheduling decisions" section in
> http://www.mythtv.org/docs/mythtv-HOWTO-12.html#ss12.2 . I wrote
> this mostly when the new scheduler went in in 0.15.x and have
> updated some stuff and it should be mostly correct today.
> Also http://www.mythtv.org/docs/mythtv-HOWTO-12.html#ss12.6
> which is more recent and touches on may relevant points.
>
>
> David Shay wrote:
> ...
> > I still would like a response to my other case around duplicates not
> > on at the same time, because at least for me, that is an important
> > case.  As for this case, though, I'm still having a little trouble
> > understanding how it would work.  Let's take a specific example.  I've
>
> There is a ProgramInfo (PI) created by the Big Ugly Query
> (BUQ) for each instance of a showing for each input that has
> a source with a chanid that has a matching showing. All
> instances of all episodes for all rules (reclist) are sorted
> into a pecking order based on priority and tie breakers listed
> in the "Scheduling decisions" section. The instance (cardinputid/
> chanid/recordid/programid) that wins is the first instance that
> can be placed on an input because it does not overlap an instance
> of a higher ranked show that has already been assigned to that
> input. If there is an overlap then another instance of the
> episode further down the list would presumably win when its
> turn comes up. Else it is a Conflict if, eventually, no instance
> for that episode can be placed.
>
> When an instance is successfully placed, all other instances for
> that episode are marked as EarlierShowing or LaterShowing. Because
> there is an instance for each input, later, all these excess
> instances are pruned so that there will only one instance for
> each episode/timeslot remaining in the reclist.
>
> A way to do a double record feature would be some variation on
> marking only the instances for the same sourceid or chanid as E
> and L. The instances for the other source or channel are still
> eligible to place the next highest rank fit.
>
> If there are no other higher ranked shows that overlap, presumably
> the earliest time slot would record for both channels. However, if
> there is an overlap for one of them, another instance at a later
> time would win automatically. You would have to add further
> restrictions to enforce that they record in the same timeslot but
> there is no need to do so.
>
> > got 4 tuners, 2 from an HD-HomeRun and 2 from a PVR-500.  On the 2
> > HD-HomeRun, I've got the same channel in both HDTV and SDTV versions.
>
> Doh! s/channel/station/
>
> <here I go again>
> These are two different frequencies with different information
> for the receiving device to tune to in order to access content
> sent over that frequency. I assume that you are saying the each
> of those frequencies carry content from the same TV station and
> therefore the TV listings for those two channels are similar.
>
> This is not semantic nit picking but critical to keep in mind
> to be clear about what is going on. Your premise is that even
> though the two listings are for the same programid in the same
> timeslot from the same callsign, one chanid has program.hdtv set
> whereas the other chanid does not. This is one of several example
> of why listings are per chanid (channel, frequency) and not per
> callsign (TV station).
> </here I go again>
>
> > So in the case of a duplicate show on at the same time, I've got that
> > show on basicaly every tuner, and in some cases twice on the same
> > tuner.  Without the HDTV flag, how do I make sure that I get exactly
> > one SDTV and one HDTV version.
>
> My point is that while this is the only situation you've been
> considering, it in not the only situation where this would be
> useful (see below).
>
>  How do you use priorities to know
> > exactly where to make the break-point between "winning"?  I'm sure I'm
> > missing something.
>
> (See the links above). You already have lots of control for what
> wins. The question is how to allow a second recording from another
> channel (frequency).
>
> > I know that the hdtv data for some could be unreliable.  For my
> > sources, however, it's pretty much dead-on-accurate.  My understanding
>
> But that still does no good for anyone in Europe, Asia, or
> digital cable vs analog or any other situation. There may
> also be a case where a show does not originate in HDTV and
> doesn't have the flag set but you still want to record from
> your HD-HomeRun and make a lower res backup.
>
> My initial thought was that a general solution was to make
> the distinction by sourceid. In addition to the instance that
> 'wins' record any other instance associate with a different
> sourceid. The source for previously recorded episodes could
> be determined by the oldrecorded.chanid
>
> Next, a little more direct and more flexible would be the same
> idea but two different chanids. The problem with either of these
> is when there are more than two chanids or sources with the
> same episode. How would it limit to two different recordings
> without trying to record a third chanid.
>
> However, I think the most powerful, flexible and easiest thing
> to implement would be an option to 'record from this channel
> number only' (chanid, really). That would allow me to make
> two rules for Big Brother 8. One in High Quality on 2128 and
> another rule in Low Quality, no commflag, auto expire off, set
> a preferred input to assure that it records on a different host
> or whatever. Each rule with this option would only match dups
> for the chanid of the rule so that each rule would record
> each episode once per chanid. I would get exactly one on 2128
> and one on 1008.
>
> You had mentioned that you were concerned about changing
> sourceids but that is more of a distraction than a real
> problem.
>
> First, while changing card numbers and inputs is a Good Thing
> and should be done as needed, wiping out video sources is very
> bad and causes lots of other problems. Renumbering cards does
> not screw with sourceid or chanid numbers. Recreating sources
> with a different number does. Most importantly, any rules for
> Single, Timeslot, Weekslot, or Channel will no longer work if
> the chanids change. These have to be fixed or recreated. The
> channum and callsign for existing recordings become "#2364 #2364"
> or whatever.
>
> As far as matching dups for double recording, changing chanids
> aren't nearly as big of a problem. First, it would only matter
> to a rule with this option. Presumably, we're talking about a
> weekly series for example. Even if the episode is repeated that
> week, it only matters for the first few days after (unadvisably)
> changing the sources. The "problem" would be that it would want
> to record again which is extra safety (as opposed to missing an
> episode) and can be fixed by simply clicking "Never record".
>
> I'd say an option to tie a rule to its specific chanid is the
> most useful for any foreseeable situation. Someone could triple
> record s show if they wanted, each with its won attributes. The
> option could be turned off if the user decides she no longer
> needs to double record or it could be turned on for an existing
> rule then add a rule for another channel (frequency) to begin
> double recording.
>
> >  If I were to go ahead and do the hdtv patch specifically as hdtv,
> > would it not be accepted?
>
> I've always have several things that I've worked on for myself
> in my own trees. Sometimes I'll eventually evolve these to where
> they are generally useful and check them in. If you want to work
> on something that is only useful to your specific situation, then
> I don't think it should go into trunk. I would not be in favor of
> a temporary hack until implementing a more general solution useful
> in other situations.
>
> --  bjm
>

First off, thanks for your complete and thoughtful response.  Second
of all, I think you've sold me on the chanid notion, or "record only
on this chanid".  Really, though, at least in my head right now, it's
still a duplicate detection type and would go with the rest of the
duplicate detection code and just modify it based on the value of this
flag to either ignore or consider chanid.

Basically, add a new field to programinfo "dupchanid" with values of
"kDupIgnoreChanID" (the default, current behaviour), and
"kDupConsiderChanID", which achieves the new desired behavior.  If you
set a new record rule, the duplicate check logic in the BUQ would be
modified to additionally check this flag.

This would be controlled by a GUI option "Consider Channel in
Duplicate Check" or some such thing on a per-record rule.

Finally, I don't want to have my own code in a separate local branch.
It would take too much time for me to maintain separate local
modifications, etc.  I also want this to benefit more people.  I had
already started last night to put the hdtv thing in, and in the
process learned quite a bit that will apply to this new, better
approach.  For one, it appears that the current duplicate detection
code is in more than one place.  It is in the BUQ, it is also in a
CompareProgram (or some similarly named function), but then it also
appears to be somewhat replicated in one or two other places just in
programinfo.cpp, and I haven't checked outside of libmythtv yet....
So any modifications to the dup check code will probably have to clean
that up.  I would hope that those other replicated versions could just
make use of CompareProgram.

Oh, and thanks for clarifying my too-loose-use of channels/stations :)

I'll start in on this approach and see how far I get.  Actually, this
will require fewer database changes as well, since chanid is already
in recorded and oldrecorded.  Thanks again for your advice.