[mythtv] Proposed scheduler patch

[Steve Davies]

On Mon, 9 Feb 2004, David Engel wrote:

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

_I_ think that it would be good to default this to "on" - I'll change this
in my local tree by removing the config option. I'll also check the
behaviour in PI::FillInRecordInfo - I'm not sure whether I updated it, but
I did try to keep everything "in order" throughout.

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

I'll put this one on hold as expected.

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

EXACTLY what I was thinking, do one of a couple of sorts at the start of
the scheduler, sort out all of the recordings, and then re-sort in
date/time order at the end.

I haven't got quite that far yet, but the SELECT statement is working...

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

I haven't done this yet, but I could try and put in the code to filter the
dupes out tonight. I assume it would be a quick single pass.

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

Unfortunately, IMHO only the scheduler has enough info to tune out
multiple inputs, as it is possible in future that the "shareable" flag
might be implemented - I hope to add this myself - to support multiple
simultaneous recordings from a single DVB mux. The existing Conflict()
check is good enough to exclude these multi-input clashes later in the
scheduling pass, but I'll certainly keep this in mind in case there in an
obvious improvement.

Kenneth, if you are reading this, do you have a current version of the
multiple recording from a single mux patch?

>
> David

I'm at work right now, but I'll try and merge your latest commit
tonight and post something this evening.

Regards,
Steve