[mythtv] Re: [mythtv-commits] Re: Ticket #643: Program matching multiple recording schedules behaves unexpectantly

[Hal Burch]

FWIW, my argument for priorities would be: If I have one rules that
says "This is X important to record" and another rule that says "This
is Y important to record", then something that matches both rules
should be at least max(X,Y) important.  Even if a user would not
certain what the behavior would be in this case, using the settings of
the schedule with a higher priority makes sense (it's as if duplicates
of the show are created and priority is used to resolve the conflict).

The specific, plausable case I gave was trying to recording first runs
and reruns at different priorities (I want reruns of show A, but
that's not as important as getting the first-runs).  The current
proposal would, if I added the rules in the wrong order, result in
everything being recorded at the priority (and recording quality, etc)
of the reruns.

That said, it may be a rare enough situation that it doesn't matter.

 - Hal

On 12/8/05, MythTV <mythtv at cvs.mythtv.org> wrote:
> #643: Program matching multiple recording schedules behaves unexpectantly
> -------------------------------+--------------------------------------------
>  Reporter:  mythtv at hburch.com  |        Owner:  gigem
>      Type:  defect             |       Status:  closed
>  Priority:  minor              |    Milestone:  unknown
> Component:  mythtv             |      Version:  head
>  Severity:  medium             |   Resolution:  fixed
> -------------------------------+--------------------------------------------
> Changes (by bjm):
>
>   * resolution:  => fixed
>   * status:  new => closed
>
> Comment:
>
>  (In [8191]) Closes #643
>
>  In cases where two recording rules match the same showing, one
>  of them needs to take precedence. An rsRepeat or rsInactive will
>  not be considered for recording so we penalize these to force
>  them to yield to a rule that may record. Otherwise, more
>  specific record type beats less specific.
>
>  The patch suggests priority as a factor but neither gigem or I
>  are comfortable with this. The controlling rule could flip-flop
>  when changing a priority on a different showing for a different
>  reason. Also, it is unknown if there would mysterious behavior
>  due to the total priority calculations (input preference, channel
>  priority) that may lead to unexpected results. Therefore, this
>  will not go in unless someone can make a very compelling argument
>  for it.
>
> --
> Ticket URL: <http://cvs.mythtv.org/trac/ticket/643>
> MythTV <http://www.mythtv.org/>
> MythTV
> _______________________________________________
> mythtv-commits mailing list
> mythtv-commits at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-commits
>
>
>