[mythtv] changes to conflict resolution

Craig Longman craigl at begeek.com
Thu Jun 5 01:04:49 EDT 2003


Matt Zimmerman wrote:

>On Wed, Jun 04, 2003 at 12:49:23AM -0400, Craig Longman wrote:
>  
>
>>i have been running with the --verbose active to help debug these sorts 
>>of problems, but it isn't printing out anything out of the ordinary. 
>>what else can i do to provide more info?
>>    
>>
>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.

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.)


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.

cheers,

    CraigL->Thx();




More information about the mythtv-dev mailing list