[mythtv] Re: Re: Re: Ticket #255: Improved scheduling
of consecutive programs with pre-roll/overrecord
bjm at lvcm.com
Thu Sep 29 00:54:08 UTC 2005
David Engel wrote:
> 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.
Right, just so no one misunderstands, I'm not opposed to adding a new
feature that people may feel would be beneficial. I wouldn't use it
myself and wouldn't recommend it others because of some pitfalls.
However, my main point is that it should be addressed up front for
what it is and not snuck in as an extension 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
Hey, I'd taken that for granted. If the endoffset is changed, the
scheduler should recalculate any extra overtime during the run.
> 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
Not sure I follow. If the magictime is stored in the settings and
the scheduler is run after an endtime change (or adding a new
recording to follow the in-progress show(!) for that matter), the
scheduler should reassess recendts by 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.
>>>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.
I see. Yes that is another point for confusion. If a system was set
for 7 minutes early and 10 minutes late magic time and there was
a show from 8-9 and a movie started on another channel at 9:20.
The show should record until 9:10 and the movie starts at 9:13.
The user sees that the show started even later and decides she needs
to record the until 9:15. She adds 5min endoffset and now the magic
time doesn't fit so the show ends at 9:05 and the movie doesn't
record until 9:20. Notice that if viewscheduled said all along that
the show's end was 9:00 then 9:05 and the movie always said 9:20,
the user would be left to their own wits to figure out that the
change had the reverse effect and they had blown the magic time.
While I'm on examples, here's a simple example of why the user
should prefer default start/end-offset over magic time. Say "The
Greatest Show in the World" has one showing at 8-9 and a priority
of +10. "Who Cares?" starring Wink Martindale is on at 9-9:30 with
priority -10. Use the same numbers, 7 minutes early and 10 minutes
late, doesn't matter. One card (or two cards and the other is
recording a long movie or sporting event).
With offsets, 'Greatest' is scheduled for 7:53-9:10. Period. It won.
Who Cares is marked "C". Now the user can see that and decide if
she wants to still record the rest of Wink at 9:10 or if Greatest
isn't really going to run late and catch Who Cares from the beginning
With magic time, The scheduler will simply say 'no problem'. Greatest
records from 7:53-9:00 and just as it is about to reach the dramatic
season ending cliffhanger, it cuts off to switch over to the crappy
More information about the mythtv-dev