[mythtv] Testers wanted for tuner affinity scheduling changes
warpme at o2.pl
Wed Oct 8 16:49:24 UTC 2014
On 07/10/14 17:30, David Engel 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.
If I want to put it on 0.27 production system (only test bed I have with
expected attributes like 5phy tuners, 20 virtual, multirec, 350 rec per
week) may You advice how minimize potential negative impact?
More information about the mythtv-dev