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

[Max Barry]

Hello devs,

Thanks for considering my patch. David's asked me to join the discussion 
here.

bjm at lvcm wrote:
> Option 1 and 2 could be made available for people who want them
> but I won't recommend them and would ask that these be turned
> off before answering any questions about odd scheduler behavior. 

I've made sure that MythTV will log what's going on. The verbose=all log 
will display the original scheduling, then any changes it's making (in 
the usual format, i.e. prepended with "+" or "-").

If there's any scheduling weirdness, you'll be able to tell whether it's 
caused by this setting, because it says what changes it makes.

> Chris Pinkham added a set a variables now called startoffset and
> endoffset. These are stored in the record rules and allow the
> minutes for the scheduled time to be adjusted. These are used
> by the scheduler to plan how things should fit hours, days or
> weeks ahead of time. These default to 0 and can be set once for
> a recurring rule or for a single showing with single record or
> an override.

IMHO this is no substitute for a global setting. In Australia every TV 
network frequently abuses its schedule (although some are worse than 
others), so if you don't use the global setting, you need to manually 
fix almost every single recording. Which is quite annoying. But more 
importantly, you end up occasionally creating unintended conflicts, 
because you're changing a hard setting.

Currently, I need to check "Upcoming Recordings" every few days and 
manually adjust the pre- and post- minutes where appropriate to make 
sure that the buffers don't cause conflicts, and cause another show to 
be missed. Then I need to remember I've done this, and put the setting 
back again afterward--otherwise next time the show runs late, I miss the 
end of it. And even if I do all this, whenever the TV network changes 
its schedule at the last minute, I'm screwed.

This seems way more complicated than it needs to be. And it's all caused 
by MythTV's hardcoded assumption that I want to dump my preroll and 
overrecord minutes rather than use my 2nd (idle) tuner card.

I simply want to be able to say this ISN'T my preference--I'd prefer to 
use the extra card and capture the buffers.

I think this is a valid point whether I'm capturing a few seconds ("as 
intended") or minutes. The issue is that MythTV is assuming a preference 
that isn't necessarily true, and there's currently no way to change it. 
That's what my patch addresses.

> The planned schedule offsets should be used to get minutes of
> content that is expected to fall outside of the TV listings times.
> The runtime recorder seconds facility should be available for
> their intended use without affecting the schedule. 

I can understand this when, as you say, ">98% of shows start and end
within the listed times." But that isn't the case in Australia, where 
98% of prime-time shows on commercial TV end OUTSIDE the listed times. 
The only really reliable schedule is the 6 o'clock news.

Living here, it makes a lot of sense to compensate with a global 
setting, because you do indeed want to apply it globally. You only want 
to deal manually with the (less common) exceptions.

gigem at comcast wrote:
> First, you are querying a number of settings from within loops. This
> causes Myth to needlessly fetch things over and over again from the
> database. The relevant settings should be queried once per scheduler
> pass.

Ah, of course, sorry. I'm happy to fix this. Am I right in thinking that 
you're referring to lines 905, 926, and 930 of my patch to scheduler.cpp?

>> 3) Apply always. This turns OverTime into a hard setting, which MythTV
>> will always obey even if this means creating a conflict.
> 
> Second, I agree with Bruce that this option isn't needed.

I must have misunderstood an earlier e-mail of yours, David, because I 
thought you requested this. It's not something I need. (Although does it 
really hurt to have the option?) You mentioned that people seemed to be 
asking for a global hard setting, so while I was here, I thought I'd 
give it to them.

No problem to drop it, though.

> I am sympathetic with those
> users with less reliable guide data and their potential need for some
> form of "softer" scheduling. 

Thanks for the sympathy. :) The unreliability of Australian TV guide 
data is half the reason I built a MythTV box. It's pretty dull sitting 
through 15 minutes of "Big Brother" waiting for "Battlestar Galactica" 
to start.

bjm at lvcm wrote:
> I'm thinking now that if there is going to be some sort of "softer"
> scheduling it should be just that, part of the schedule planning.
[...]
 > These could be applied to the schedule in the context
 > of scheduling and shown in the Upcoming Recordings (reclist) for
 > the users to fix whatever problems they create for themselves.

Perhaps I misunderstand what you're getting at, but that's exactly what 
my patch does. It lets MythTV adjust the schedule to (for example) 
assign a future program to an idle tuner card, and you can see it's done 
this in "Upcoming Recordings."

> We should leave the preroll seconds out of it and limit their range
> to 0-29 seconds to be applied by the recorder at record time as it
> is now. 

I really don't know if MythTV needs another set of global buffer 
options. I think it's simpler and more intuitive to have one setting and 
ask users how they want it to work.

Otherwise you end up with multiple settings for what is, at least at 
first glance, the same thing. If a new pair of global setting was added, 
MythTV would have 3 different ways to set pre- and post- buffers (two 
global, one rule-specific), which seems a little excessive.

anonymous wrote:
> Shouldn't there be an additional option - "Apply unless it would
> cause a conflict or require MythTV to record an earlier or later showing" -
 > for people who don't mind tying up all their tuners briefly (e.g.
 > because they don't use LiveTV mode anyway, all their tuners are
 > equally good, etc) but don't want their recordings delayed?

This sounds sensible, and I'm happy to add it if devs agree.

Thanks for the feedback! This is an interesting process. And, since I'm 
here, thanks also to all devs for making such a wonderful piece of 
software. It's practically changed my life. :)

Max.