[mythtv] Proposed scheduler patch

[David Engel]

On Mon, Feb 09, 2004 at 09:07:10PM +0000, Steve Davies wrote:
> I am just about keeping up with your patches at present, and fixing merge 
> differences between your tree and my local "play" area. 

I was wondering if you were going to "play along" or wait until I was
finished. :)

> I have 2 or 3 
> patches which may be of interest - Perhaps you could tell me if you would 
> like to see them tidied up and posted, or whether I should wait a while 
> longer - You are being quite prolific recently :-)
> 
> 1) The "xmltvid is global" patch which I've posted previously - I 
> accidentally turned this off the other day, and BOY does it make a 
> difference. I can provide a trimmed down version which does nothing but add 
> this feature.

I was hoping you would take this up when I was done since I don't have
multiple sources and wouldn't have any easy way of testing it.  I do
have a couple of questions for you in the mean time.  First, is there
any reason a user wouldn't want this always enabled?  I'm all for
configurability, but not when make things more complicated than it
needs to be.  Second, have you thought about making sure
PI::FillInRecordInfo does the right thing?  It currently looks for an
exact match on chanid.

> 2) The "DoFixup" patch which was part of my previous submission - I assume 
> that this will eventually become redundant as some of your planned changes 
> are rolled in, so unless you think there is value in a single pass fixup to 
> catch the worst cases of mis-scheduling, I'll leave this one out.

It might be redundant and it might not.  I haven't gotten that far
yet.  Stay tuned.

> 3) A new "concept" patch - I have modified the scheduled programs SELECT 
> statement to select all instances of all programs on all sources, and to 
> pre-fill the cardid and inputid values - Then by modifying the duplicates 
> matching slightly, the duplicates are marked as "rsOtherRecording" entries 
> - this means that the DoMultiCard() and associated calls can be removed. 

This is interesting and could easily solve a problem I was going to
encounter.  To make the most people happy, I was expecting to have to
implement two slightly different alogorithms, one which schedules one
card at a time and another which schedules across cards.  With this
approach, I could probably get by with one algorithm and control the
behavior by how I sort the possibilities.  Please update you patch and
post it to the list after do my next commit later this evening.

> It 
> would be best to prune some of these duplicates fully at a later stage (for 
> aesthetic reasons), but I would be interested in feedback on the concept - 
> It is working very well here so far. This patch overlaps slightly with the 
> xmltv patch in 1) due to the duplicate matching code.

Pruning would most definitely be needed to keep from confusing the
user (and me).  They wouldn't want to see three, four or more entries
show up when they only scheduled one program!  Does your patch try to
filter out multiple inputs on the same card?  Since you can't use more
than one input at a time on a card, it would be nice to remove the
redundant entries as early as possible, ideally in the SELECT.

David
-- 
David Engel
dlengel at attbi.com