[mythtv] changes to conflict resolution
Matt Zimmerman
mdz at debian.org
Sun Jun 8 23:12:04 EDT 2003
On Thu, Jun 05, 2003 at 01:10:24AM -0400, Craig Longman wrote:
> Matt Zimmerman wrote:
> >Can you send your patch? This should probably be fixed.
> >
> i will. it works pretty well. the main scheduler server still gets
> 'the right stuff', removing ones that shouldn't be recorded, but the
> resolve conflicts now gets the full list, with the ones that PruneList()
> was removing now greyed out. it makes _much_ more sense to me now, its
> pretty neat the way it does basic conflict resolving actually. cool!
>
> anyway, the patch is attached. its pretty basic, i've tried to comment
> what i've done and what the code actually does (afaict, if its
> incorrect, please remove it, the only thing worse than no comments are
> inaccurate comments).
>
> it reuses the ProgramInfo::duplicate member a bit though, where as
> before duplicate really did mean something was already recorded (as the
> 'unsuppress recording' option indicates), now it could also mean two
> more things:
> 1) it is going to be recorded before this airing
> 2) it is going to be recorded after this airing, but because this one
> conflicts and the next one doesn't, we've opted to record the next one.
> i can't quite read all the text of the new 'unsuppress recording'
> dialog, but we might want to update that text to at least allude to the
> other meanings of duplicates.
I am wondering if that logic maybe should go away entirely. The scheduler
will recalculate things after it does a recording, so duplicates will be
handled by the oldrecorded mechanism.
Your patch, like mine, will cause some strange things to happen in the
viewscheduled screen, so I don't think it's quite the right thing to do at
this point. I've been busy with other stuff, but I'll probably revisit this
issue after the 0.9 release.
--
- mdz
More information about the mythtv-dev
mailing list