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 [EMAIL PROTECTED]
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
