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

[Bruce Markey]

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