[mythtv-users] Show matching two searches not recorded

Michael T. Dean mtdean at thirdcontact.com
Tue May 6 15:01:43 UTC 2014


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


More information about the mythtv-users mailing list