[mythtv] Re: [mythtv-commits] Re: Ticket #255: Improved scheduling
of consecutive programs with pre-roll/overrecord
Max Barry
mythtv at maxbarry.com
Wed Sep 28 06:16:43 UTC 2005
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.
More information about the mythtv-dev
mailing list