[mythtv] Testers wanted for tuner affinity scheduling changes

[David Engel]

On Wed, Oct 08, 2014 at 03:54:09PM +1100, Jean-Yves Avenard wrote:
> On 8 October 2014 02:30, David Engel <david at istwok.net> wrote:
> > On Mon, Oct 06, 2014 at 10:25:32PM +0000, Git Repo Owner wrote:
> >> The branch, devel/scheduler has been created on the
> >> mythtv repository by gitolite user gigem.
> >>         at  c25ce976be95ad6de14aa80995bc1c02ae8051d2 (commit)
> >>
> >> - Log -----------------------------------------------------------------
> >> commit c25ce976be95ad6de14aa80995bc1c02ae8051d2
> >> Author:    David Engel <dengel at mythtv.org> at Mon, 6 Oct 2014 16:23:33 -0500
> >> Committer: David Engel <dengel at mythtv.org> at Mon, 6 Oct 2014 16:23:33 -0500
> >> URL:       http://code.mythtv.org/cgit/mythtv/commit/?id=c25ce976be95ad6de14aa80995bc1c02ae8051d2
> >>
> >> Change the scheduler to partly use best-fit based on tuner affinity.
> >> If one or more programs on a multiplex or chanid are scheduled to
> >> record on a virtual tuner, the scheduler now tries to schedule other,
> >> overlapping programs on the same multiplex or chanid on related
> >> virtual tuners.  In the past, the scheduler always used the first
> >> available tuner even if doing so caused it to paint itself into a
> >> corner.  The intent of this change is to make better use of virtual
> >> tuners by grouping compatible recordings together when possible.
> >>
> >> The scheduler currently does this best-fit scheduling in two places.
> >> In the first pass, it checks all showings of the program at the given
> >> time.  Later showing of the program are not considered at this time.
> >> In the retry passes when trying to move already scheduled programs,
> >> all showings of a program, even later ones, are checked.
> >>
> >> Note that this change also makes subtle changes in the order programs
> >> are tried and retried.  In the first pass, programs in the same
> >> priority/subpriority (aks recpriority2) sublevel are scheduled.  In
> >> the first retry pass, programs in the same priority/subpriority
> >> sublevel are scheduled by moving other programs as long as their
> >> priority is not lowered.  In the second retyr pass, Programs in the
> >> same priority level are scheduled by moveing other programs even if
> >> their priorities get lowered.  The intent of this change is to try a
> >> little harder to schedule the highest priority for a given program.
> >> Previously, the scheduler was a little too quick to fall back to lower
> >> priority showings.
> >>
> >> Note that there are more changes that will be considered in the
> >> future, possibly even adding more levels of retries.  Those won't be
> >> started, though, until after some infrastructure changes are made and
> >> those are expected to take a while.
> >
> > I'm looking for testers of this change before pushing it to master.
> > Ideal candidates should have multiple multirec capable tuners with
> > each having multiple virtual tuners.  You do not have to run this
> > version in production.  At this point I just want to see debug output
> > from running in test mode.
> >
> > If you want to help out, checkout the devel/scheduler branch from git
> > and build it normally.  Then run the following command with both this
> > test version and your production backend and send me the output.
> >
> > mythbackend -v schedule --loglevel --testsched
> >
> > I also have a version of this change as a patch to 0.27-fixes if
> > anyone is interested in helping, but isn't running master yet.
> > Contact me and I'll send you the patch.
> >
> 
> I wouldn't mind testing for 0.27 install... would be easier and
> provide more coverage seeing that it's a much more used setup than my
> pre-0.28 setup

Alright.  Seeing that it compresses down pretty well, I'll just attach
it here.

FYI, I know a lot of users go crazy and assign many different
priorities to recording rules.  My expectation is that this change
will generate a better result with fewer priorities.  For example,
only use 1 and 0 for high and low, respectively, or at most 1, 0 and
-1 for high, medium and low, respectively.

David
-- 
David Engel
david at istwok.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: affinity-wip4-0.27.diff.gz
Type: application/gzip
Size: 5269 bytes
Desc: not available
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20141008/53160fdd/attachment.bin>