[mythtv] changes to conflict resolution

Matt Zimmerman mdz at debian.org
Thu Jun 5 01:16:40 EDT 2003


On Thu, Jun 05, 2003 at 12:04:49AM -0400, Craig Longman wrote:

> Matt Zimmerman wrote:
> >Run the scheduler query (pull it out of the mysql logfile or from
> >scheduledrecording.cpp) and see what it returns.  Compare that to
> >mythbackend --printsched.
> >
> ahh, --printsched, that's what i was looking for thanks.
> 
> however, going through the code, i think i'm actually seeing the correct 
> behaviour.  one thing that really confused me, was that in the 
> Scheduler::PruneList(), entries are completely removed if they
>  a) haven't been recorded before, or
>  b) have a conflict and there ist another showing.

There are actually two lists in the scheduler:

- the list of stuff which matches scheduled recordings
- the list of stuff to actually record

The first is what is displayed in the EPG, the second is what is used to
actually record programs.  The first is a superset of the second.

I think the current code is a bit confusing because in some cases, things
are simply removed from the list early on, and in other cases, they are
marked as not recording, at which point they are removed from the second
list later (RemoveConflicts).

> this is confusing, cause old recordings _are_ still included in the list.
> i had just assumed that if the old recordings were still being shown, then
> other recordings that hadn't been recorded yet would also show up.  in
> fact, i really do think that completely removing them from the list is not
> the right thing to do.  or at least, it should be consistent, if the
> unrecoded dupes don't show up, then the previously recorded dupes probably
> shouldn't either.  although i personally would like both of them to show
> up with the ProgramInfo::recording set to false  (at least that's what i
> think makes the previously recorded show up darkened, haven't got that far
> yet.)

There are two types of duplicates:

- programs which have been recorded in the past (oldrecorded)
- programs which occur twice during the same scheduling run

I think the code handles the two of them inconsistently at present.  They
should probably be handled the same inside the scheduler.

> anyway, i've just changed the behaviour of PruneList to not actually
> remove the entries, but simply mark them as not being recorded.  they will
> get removed from the list if the doautoconflicts parm is true.  i'll have
> a better idea of whats going on when i can actually see the programs that
> should be recorded and which ones are being selected.

Can you send your patch?  This should probably be fixed.

-- 
 - mdz


More information about the mythtv-dev mailing list