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

David Engel gigem at comcast.net
Wed Sep 28 22:33:50 UTC 2005

On Wed, Sep 28, 2005 at 01:18:14AM -0700, Bruce Markey wrote:
> David Engel wrote:
> >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

I think we agree.  My point is that if we want to support soft
scheduling, we should add first class support for it and not let it
just fall out as a result of mis-using pre/post-roll.

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

What about the in-progress end-time support we just added?  It keys
off detecting changes between the new end-time and what it was when
the recording was started.  To know if the user changed the end-time,
we would need to remember if (and maybe how much of) a magictime was

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


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

Boy, I screred up that question.  It should been along the lines what
if the user adjust the start-early or end-late settings and nothing
changes?  This could happen if partial padding was done.

David Engel
gigem at comcast.net

More information about the mythtv-dev mailing list