[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
added.
> >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.
Agreed.
> >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
--
David Engel
gigem at comcast.net
More information about the mythtv-dev
mailing list