[mythtv] More scheduling scheduler

Paul Andreassen paulx at andreassen.com.au
Sat Jul 15 04:58:03 UTC 2006


On Wed, 5 Jul 2006 04:08 pm, Max Barry wrote:
> The problem there is that SchedMoveHigher is disabled by default. So we
> would have some default situations in which soft padding becomes hard.
> And that would be very bad. The difference between soft and hard padding
> is already a little hard to grasp, without having one type unexpectedly
> transform into the other.
>
> If SchedMoveHigher was *enabled* by default, then I can see there's a
> case to be made that when someone wants to set their high-priority shows
> in stone, and signals this by turning off SchedMoveHigher, he also wants
> his soft padding to turn hard. That's may be true in many cases...
> although I don't know if it's true for all of them. I'm a little wary
> because they are two related but distinct behaviors.
>
> But anyway, that's not the situation. Our default behavior must be that
> soft padding is indeed always soft.
>
> Is it possible to fix whatever is causing this occasional sub-optimal
> scheduling without violating that concept?

All very true.  Lets get it to work better first and then tackle this problem.

I'll explain how the scheduler currently works in the hope I get a better 
understand.

Scheduler::SchedNewRecords loops through all possible recordings and tries to 
enable them, any conflicts are added to a retry list.  The higher priority 
shows are enabled first and each time the priority lowers, 
Scheduler::MoveHigherRecords is called.

Scheduler::MoveHigherRecords loops through the retry list, testing each show 
by enabling it and trying to fix all its conflicts with 
Scheduler::TryAnotherShowing.

Scheduler::TryAnotherShowing tries to move its show to another time and 
returns if its been successful.

Simple and very effective.

Some scheduling problems go away if we could record multiple times from the 
same transponder/source.

Paul
-- 


More information about the mythtv-dev mailing list