[mythtv-users] Show matching two searches not recorded

Tue May 6 17:30:26 UTC 2014

On Tue, May 06, 2014 at 11:01:43AM -0400, Michael T. Dean wrote:
> On 05/06/2014 10:35 AM, David Engel wrote:
> >On Tue, May 06, 2014 at 09:22:52AM -0400, Michael T. Dean wrote:
> >>On 05/06/2014 07:45 AM, Nathan Wray wrote:
> >>>Hi all, I've had a bit of trouble with a show that matches two different
> >>>schedules with different priorities. I'd consider the behaviour I'm seeing
> >>>a bug but I'd appreciate any feedback on fixes.
> >>>
> >>>1) I have a PowerSearch named "HD Documentary" that is set to priority
> >>>(-10), with a definition "program.hdtv>  0 AND program.category =
> >>>'Documentary' ".
> >>>2) I have a specific schedule for "Cosmos" any time/any channel, HD, with
> >>>a priority of 99.
> >>>
> >>>When I click on Cosmos, it says it won't record it because it matches "HD
> >>>Documentary" and there are more important things to record like Spongebob
> >>>re-runs, due to the low priority on that schedule. If I disable "HD
> >>>Documentary" it correctly records Cosmos.
> >>>
> >>>I would expect that if a show matches multiple searches, it would apply
> >>>max(priority) - is there something I'm overlooking here?
> >>I'd need to see the output of mythbackend --printsched to know exactly what
> >>was happening, but it's possible you were just being shown the wrong
> >>information and it would have recorded, anyway.  If that's the case, it's a
> >>known bug in the display code that's being worked on (and/or fixed in a more
> >>recent version than you have).
> >It's very likely exactly as the OP described.  When two recording
> >rules match the same program, MythTV has a very specific method of
> >determining which rule 'wins'.  A former developer felt very strongly
> >that recording rule priority *not* be used in such cases, so it isn't.
> >I don't remember his argument, but if someone wants to work up a patch
> >to change it, I'll consider applying it.
> 
> http://www.gossamer-threads.com/lists/mythtv/dev/166447#166447
> and
> https://code.mythtv.org/trac/ticket/643#comment:3
> 
> prompted by the bug report at on https://code.mythtv.org/trac/ticket/643
> 
> The argument does make sense.

I was hoping the spherybot would kick in.

> It also sounds like the "fix" (where "fix" means, "make it work in this
> situation as Nathan wants") is to remove the custom rule, then create a new,
> identical custom rule so that the Cosmos rule is "older" than the custom
> rule.  Or did I misunderstand?

Yes, the way things currently are, that is the way to do it.

On Tue, May 06, 2014 at 12:14:10PM -0400, Michael T. Dean wrote:
> There was a proposal*** by a scheduling genius to completely remove the
> "pick some number between -99 and +99 to represent the priority for your
> show, even though you don't remember the priorities of the other 142
> recording rules that already exist" and, instead, to put new rules at the
> "top" (highest "priority"--or was it bottom?) of the list (though possibly

I think the last idea was to put new rules right above or below the
default, or other applicable, template rule.

> different tops based on rule type) and allow users to adjust which rules
> take precedence over others by moving rules up and down the list with an
> interface similar to what you describe (as appropriate based on user
> interface--such that it's remote-accessible in mythfrontend, etc).
> Especially since priority is generally not necessary (most rules should have
> a default priority unless there are specific and recurring conflicts which
> need to be resolved) and since a single, definitive ordering of rules
> against all others would allow users to know the exact effect of their
> changes, this simple approach would just Do The Right Thing for almost all
> new rules for almost all users but would let any user fine tune the ordering
> as needed when necessary.
> 
> As I understood the proposal, it would also make this "should we use
> priority to determine which rule wins when multiple rules match a show"

No, I don't believe that was part of the proposal.

Some form of precedence favoring specificity over priority must
remain.  Here are the precedence levels I would propose:

Don't Record
Override Record
Single Record
All Record
Find Daily
Find Weekly
Find One Record

Within each precedence level, priority is used, followed by order of
creation.  Note the find rules should have low precedence because they
can artificially cause other programs to be considered duplicates and
not allow them to record until the next find period.

> issue a moot point because users would specifically say which rules should
> win over which others when they move up/down rules in the list, and users
> would always see the exact "resolution" of changes (any rule below this one
> would be overridden when this one matches/matches of this rule would record
> in preference to matches of rules below this one).  The fact that we would
> not be using exact values to specify priority, but instead a relative
> ordering of rules, would allow us to remove the existing priority value on
> the recording rule and use the rule order to determine which rule takes
> precedence without the issues described in that post--you'd see the other
> rules that get bumped over or under this rule as you change things.
> 
> Mike
> 
> 
> *** And, no, I'm not just intentionally posting this to try to get user
> support for the idea (and to get that developer to consider re-proposing it)
> because I loved the idea even though many others felt that the "whatever
> number I choose between -99 and +99 at the point when I schedule a TV
> recording rule is the exact and proper priority value for that show,
> regardless of future changes to the broadcast schedule, not to mention the
> fact that in 6 months when I create a new rule I won't remember that I chose
> +72 for this show and so need to use a value >+72 for the new,
> more-important recording rule I'll be creating" priority is much better and
> more intuitive.  But if people started to consider potential benefits for
> such a radical departure from our current
> 1980s^H^H^H^H^Hpriority-as-a-number-based scheduling approach, I wouldn't be
> upset...  ;)

On Tue, May 06, 2014 at 12:47:24PM -0400, Michael T. Dean wrote:
> On 05/06/2014 12:36 PM, Hika van den Hoven wrote:
> >I think it an excellent idea, because it's intuitive and visual. Only
> >you should find a way to integrate it with the rest of the priority
> >chain. Channel priority etc.
> 
> I'm pretty sure these would work pretty much the same as before, but may be
> simplified a bit.

Pretty much unchanged.

David
-- 
David Engel
david at istwok.net