On Fri, Apr 14, 2006 at 08:49:18AM +1000, Paul Andreassen wrote:
> On Fri, 14 Apr 2006 06:24 am, David Engel wrote:
> > Thanks. I created a branch called softpad for these changes to go
> > into. People who want this feature should help test it out.
>
> Are we at this stage already? Cool.
I think so. The core scheduling changes are just an update of the
previous proof-of-concept. There are some usability issues (see
below) which will have to be worked out though. That's one reason
this is on a branch.
Another reason for having a branch is to make it easier for would be
testers with patchophobia to try it out. I must add that anyone who
wants to see this merged into trunk needs to help test it. Unless
there's feedback, positive or negative, I will let it die on the vine
like previous attempts.
> > Don't apply soft padding at the start or end if corresponding hard
> > padding has already been added. Hard padding is limited to a
> > resolution of 1 minute so they can't currently be mixed.
>
> I can't see why you can't mix soft and hard padding. If you take out your
> test, it should just work.
Consider the following examples, both of which have SchedSoftEnd set
to 1200 seconds (20 minutes) and endoffset initially set to 0 minutes.
Also note the same issues apply to SchedSoftStart and startoffset as
well.
A program with softend added is scheduled to end at 9:20. The user
thinks that might not be late enough and changes endoffset to 15
minutes. There happens to be another program scheduled to record at
9:30 and it can't be moved. Since the softend can no longer be
applied, the scheduler changes recendts to 9:15.
A program without softend added is scheduled to end at 9:00. Again,
the user wants more time and changes endoffset to 15. That bumps a
program scheduled to start at 9:00 to some other place or time.
Softend can now be added so the scheduler changes recendts to 9:35.
In both examples, the resulting recendts is nonintuitive.
OK, the obvious solution is to automatically absorb softend into
endoffset when the recording rule is edited. That presents new
problems.
First, say the user goes to edit something else about a recurring rule
and they access it through the EPG. If that showing happened to have
softend added, they've now inadvertantly added that softend into the
endoffset for that rule. The only way to not do this would be to
access the rule through the Set Priorities screen since it doesn't
have specific showings tied to recurring rules.
FYI, this is why the ability to change the end time of an in-progress
recording has a separate button for doing that. It creates a
kOverride rule on the fly as needed so this won't happen.
Second, endoffset might get adjusted every time the rule is edited.
In other words, endoffset could keep growing higher and higher.
In the end, I think the simplest, most deterministic thing to do is
not add softend when endoffset is non-zero. The rationale is that if
the user went to the trouble of specifying endoffset, they probably
had a reason and that should be the exact end time.
There is another related nit regarding interaction of softend and
endoffset. Softend is specified in seconds, but endoffset is in
minutes. If softend needs to get absorbed into endoffset, it will
have to be rounded to a minute boundary. The simple fix for this is
to change softend (and softstart) to be minutes instead of seconds.
> > Pass softend to the recorder when a recording starts. This is needed
> > so the recorder can pass it back to the scheduler if the master
> > backend gets restarted.
>
> I didn't know how that worked.
I didn't expect you to. It was a simple enough fix so I just added it
myself.
David
--
David Engel
gigem@comcast.net
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
