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 <[EMAIL PROTECTED]> wrote: > #643: Program matching multiple recording schedules behaves unexpectantly > -------------------------------+-------------------------------------------- > Reporter: [EMAIL PROTECTED] | 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 > [email protected] > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-commits > > > _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
