[mythtv-users] Show matching two searches not recorded

Nathan Wray mythtv at detroitsci.com
Tue May 6 15:19:10 UTC 2014


It seemed obvious to me that max(priority) would be ideal but I hadn't
considered the "negative scheduling" case where you're specifically trying
to push something down, like "don't record Simpsons reruns on Tuesdays".

For me, priority is how important the recording is to me, and applying
max(priority) would make the results more intuitive.  I'm not entirely
convinced this isn't the case but it's nice to be aware of the
counterargument.

The system seems to be using "first rule wins", which is workable but
non-obvious since it isn't surfaced that way in MythWeb.  Ideally there
would be a drag-and-drop interface in MythWeb that explicitly lets you
order your rules.





On Tue, May 6, 2014 at 11:01 AM, Michael T. Dean <mtdean at thirdcontact.com>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.
>
> 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?
>
> Mike
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140506/5fd3ea57/attachment.html>


More information about the mythtv-users mailing list