[mythtv] Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord

Bruce Markey bjm at lvcm.com
Wed Sep 28 08:18:14 UTC 2005


David Engel wrote:
> On Tue, Sep 27, 2005 at 01:25:19AM -0700, Bruce Markey wrote:
> 
>>I'm thinking now that if there is going to be some sort of "softer"
>>scheduling it should be just that, part of the schedule planning.
>>I think it would make more sense to have a pair of variables for
>>this, expressed in minutes, rather than usurping the preroll
>>variables. 
> 
> 
> That sounds appealing conceptually.  However, I fear the changes to
> the scheduler would be more invasive than I would like.  The current,

Doesn't parse. There are the same issues no matter what the variables
are named. What I'm saying is that the pre-roll is a useful feature
and it should not be abandoned. Whatever this magic behavior is, it
can be implemented using a different set of variables without usurping
the existing leader time. Further, apparently this behavior is thought
of in terms of minutes. I wouldn't expect that someone would insist
that it be set to 6:37 (397sec) or such. Call a spade a spade and
leave preroll out of it.

> abused, post-roll mechanism is nice to the scheduler in that it is
> fire and forget.  Making the scheduler more aware of soft padding
> would mean keeping track of when the padding has been added and when
> it hasn't, informing a recorder when the padding has to be changed
> after the fact, etc.

It shouldn't change after the fact. Either it should plan to start
five minutes early or it shouldn't. Recstartts and recendts should
reflect what is planned at the end of placement in a pass after the
initial placement much like SMH. This doesn't need to tracked but
regenerated on each run. Endts + endoffset + magictime if it fits.

> Full soft padding could also open up whole new cans of worms.  What if
> some, but not all, of the soft padding between two programs could be
> honored, should the scheduler split the difference?  Should that

Guess what? it's problematic. What should happen in this instance
no matter how it's approached. Whatever the decision is should be
reflected in the reclist and not a surprise after the fact.

> behavior be different if the programs ares on the same channel.
> Should the scheduler try to force back to back (with or without
> padding) programs on the same channel to the same card?  ...

Same thing. How should that situation be handled no matter how it's
approached? Whatever the algorithm, viewscheduled should show what
that decision will be so the user knows what to expect. Keeping the user
in the dark won't make the behavior any better no matter how strongly
anyone believes that by keeping their eyes shut, an ambiguous feature
will automatically solve all their scheduling problems.

Not letting the user know what was going to happen until it came
time to start recording is, I believe, one of the many reasons that
SonicBlue went bankrupt.

>>These could be applied to the schedule in the context
>>of scheduling and shown in the Upcoming Recordings (reclist) for
>>the users to fix whatever problems they create for themselves.
> 
> 
> That could lead to some strange things.  What if the user tries to fix
> things up by adjusting the hard start-early or end-late settings and
> instead winds up receiving a whole new scheduling result?

Currently, changing the offsets for consecutive recordings can result
in a whole new schedule so I fail to see the point as far as making
changes affecting other things in the schedule. That's a given. If
you mean that it would become like herding kittens to try to control
your schedule, I agree and this is one of my concerns. I wouldn't
want to field question like 'why can't I record one of my favorite
shows on card 1 no matter how I set the priority' or 'why can't I
get this to record on my digital input rather than analog' or 'I
can't record Nova on Tuesday unless I "Don't record" Nip/Tuck even
though they are on at different times'.

--  bjm


More information about the mythtv-dev mailing list