[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