[mythtv] Re: Ticket #255: Improved scheduling of consecutive
programs with pre-roll/overrecord
mythtv at maxbarry.com
Thu Sep 29 05:56:03 UTC 2005
Bruce Markey wrote:
> If you've followed these lists at all, people are often confused
> by things much less intricate than this. Why scheduling decisions
> don't make sense is not resolved by -v all and telling them to look
> through the logs for "+" or "-". That doesn't explain what happened
> to them last night and why (BTW it should be -v schedule anyway).
True enough, but just to clear this up, I was responding to your comment
that you wouldn't help people until they disabled this feature entirely.
I merely meant to point out that you wouldn't need to do that, because
you could look at the logs.
> Also, if the plan is to record an 8 o'clock show from 7:55 until
> 9:10, the Upcoming Recordings page should reflect this known plan
> rather than saying 8-9 and leave it to the user to remember, guess
> or dig through the logs.
I guess that'd be nice. But it's not what MythTV does now: i.e. a
60-second preroll doesn't get reflected in "Upcoming Recordings." I
know, I know, preroll was never intended to record minutes' worth. But
I'm not attempting to make big changes, just to turn one hardcoded
assumption into a user-malleable setting.
> "Global" isn't the distinguishing feature here. Having a default
> offset setting for offsets would be global with the advantage that
> it could then be re-adjusted on a per rule basis rather than blindly
> applied (or considered) in all cases.
That would be handy, but only a little, because the great advantage of
the preroll/overrecord feature is its softness. You say you don't
believe me on this, so I'll address it in detail a little later.
Personally I think default start-early/finish-late is a good idea and
should be added to MythTV. But so long as that's a hard setting, it
won't address the problem that people with unreliable guide data have.
> If there are showss that must be recorded consecutively and
> the times are not reliable then these need to be considered on a
> case by case basis.
Sure, if there are only a few shows that are unreliable. But it's not
very practical to deal with the majority of recordings (and not just
recordings: showings!) on a case-by-case basis.
>> But more
>> importantly, you end up occasionally creating unintended conflicts,
>> because you're changing a hard setting.
> This is where it becomes magic. I'm thinking of a one hour show at 8PM
> and another at 9. Can you please tell me if the 8 o'clock show I'm
> thinking of runs past 21:00:00? Yes or no? Use whatever algorithm
> you'd like but tell me for a fact if it is okay to stop recording at 9.
Bruce, you seem set on this idea that programs mostly fall within their
scheduled time. I envy you, but it's not the situation here. The fact
is, in Australia it /is/ a lottery as to when shows actually screen.
Indeed, MythTV cannot know for a fact when they will screen, as you say,
but neither can I, as the user.
You must realize that I'm not here thinking, "I know Battlestar
Galactica always starts 12 minutes late, but I can't be bothered just
entering that myself, so I want a global default." Rather, I'm thinking,
"I don't know exactly when all TV shows will screen, so I want to
capture a reasonable buffer around them where possible."
Faced with guide data uncertainty and limited resources in terms of hard
disk space and tuner cards, the best you can do is stack the odds in
your favour. That means applying a pre- and post-recording buffer when
it's sensible to do so, but junking it and taking your chances when it's
> Exactly. You, as a human being that watches the shows, know which
> shows are likely to have content outside the scheduled time and
> you know what adjustments are appropriate.
With respect, this is where you're wrong. Most of the time, I don't know
that. Sometimes I do, and this is when I manually change the start and
end times, just like I'm supposed to. But the fundamental problem is
that in Australia TV shows frequently run unexpectedly late (and
occasionally unexpectedly early), and you don't know for sure which
>> Then I need to remember I've done this, and put the setting
>> back again afterward
> Um, no. That is what overrides are for.
Ah, yes, you are correct. I could have done that.
> If you're going to miss the end of next week's show unless there
> is time added at the end then you missed the end of this week's
> show when the time was not added.
Unfortunately, it doesn't follow that because The Simpsons ran 4 minutes
late tonight, it will also run 4 minutes late tomorrow. It might, but it
might not. It's precisely because of this uncertainty that there's a
need for a soft global pre- and post-recording buffer.
> I won't believe for a second that it will happen to fit if there
> isn't room for extra time and will not fit in just the cases where
> there is room for extra time.
When you have unreliable guide data, you cannot be 100% sure of
anything. All you can do is maximize your chances of catching the
programs you want, within the limited resources you have.
>> And even if I do all this, whenever the TV network changes
>> its schedule at the last minute, I'm screwed.
> I don't even know where to begin here. How on earth would you
> be assured of not being screwed by a schedule change if the
> behavior was optional and ambiguous?
Well, there is no "assured," because as I mentioned, all you can do with
unreliable guide data & limited resources is play the odds. But the
answer is that if you could tell MythTV to more aggressively try to
honour soft pre- and post- buffers, this would increase your odds.
What I'm talking about here is not a schedule change of the "The O.C.
will not screen tonight" variety, but when the network shuffles its
shows and suddenly your post-recording buffer gives you a hard conflict.
You don't always get time to fix this before you've missed something.
> The preroll was created to be used by the
> recorder at record time and deliberately should not impact the schedule.
> You've decided that the existing variables should be re-interpreted
> to affect the schedule. I disagree and don't want to have the
> preroll feature trashed simply because you choose to not see it's
I understand that and respect it, although I will point out that plenty
of us are already abusing preroll and overrecord, because it's currently
the only way to get MythTV to apply a global soft buffer. I'm not
creating that situation. The patch just adds a small amount of increased
utility for people who need a global soft buffer, without impacting
>> 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.
> Again, this is your mis-interpretation written after I'd explained
> where the preroll variable came from. If your quotes around "as
> intended" were meant to be sarcastic, I'll have very little patience
> for that.
I don't know why you're being hostile; I was just quoting you. I know
why preroll and overrecord were created.
> And that suggests that there should be default offsets for new rules.
> Leaving the extra time up to hit or miss happenstance is not a
Actually, it kinda is. If you have 100% reliable guide data, then no
doubt things are nice and easy and you can tell in advance whether you
have the resources to fully capture a TV showing.
But when you don't have reliable guide data, you can't avoid
happenstance. Even my patch doesn't eliminate that; it just helps users
deal with it. You can never be sure that you're going to catch all of
> Based on your own statistics, 49 out of 50 times that the
> extra time is not applied you will miss content.
That's prime-time; it's not quite so bad at other times. But I'd guess
that around 8 out of 10 Australian TV shows run outside the exact
scheduled time by at least 1 minute, often more like 5, and not
infrequently 15 - 20.
Now I think you're asking, "If that's the case, why do you want a soft
setting? You need a hard one, or you'll miss content." To answer I'll
give you an example. Let's say I want to record these shows:
6:00 - 6:30 Arrested Development
6:30 - 7:00 The Simpsons
For simplicity say they're on the same channel and I only have 1 tuner.
Because I have unreliable guide data, I want pre-recording buffers of 2
minutes and post-recording buffers of 12 minutes.
If those buffers are hard (e.g. set manually, as is the only possibility
at the moment), here's what MythTV will schedule:
5:58 - 6:42 Arrested Development
The Simpsons -- CONFLICT, NOT RECORDED
If the buffers are soft, though, I get everything, because the
in-between buffers are dumped so as to not create a conflict. There's a
good chance I'll get the end of Arrested Development on the start of The
Simpsons, but this is much better than missing The Simpsons altogether.
This is why preroll and post-record are so useful: not just because
they're global but also because they're soft.
The main problem at present is that they're occasionally TOO soft, in
that MythTV will dump them in order to keep a tuner card idle. Consider
the same example, but say the shows are on different channels. At the
moment, MythTV will dump the buffers, thus risking missing the end of
Arrested Development, in order to get both recordings with the one card.
I know this annoys many people, so my patch lets you tell MythTV to use
both cards to get the shows plus the buffers. That's all. I don't think
it's a big change, and certainly doesn't prevent some of the things you
and David are discussing from being implemented.
> IOW, it's simpler for you to blow off a worthwhile feature and
> reuse the variables as you see fit? I disagree.
Well, I would argue that users with unreliable guide data are already
(mis-)using this feature in this way, because it makes the software more
valuable. My patch doesn't create that situation. It doesn't make it
better or worse.
>> Otherwise you end up with multiple settings for what is, at least at
>> first glance,
> In case you didn't know, I'm well past the first glance.
Again, Bruce, I'm not sure why you're being so hostile. Clearly I'm not
talking about you; I was considering how it might look to a new MythTV user.
> Preroll was created to give the
> recorder a head start before the scheduled time to allow for
> initialization. It was not intended to assure capturing content
> outside of the times in the TV listings. These are very different
> features to serve very different needs. It is the perception that
> the ability of the recorder to start a few seconds early could be
> used as a substitute for planning to have the scheduler include
> content outside the listings time which is the point of confusion.
> If you do want minutes of time to record content outside the time
> in the listings, face up to it, use new variable names, account for
> the time while planning the schedule and reflect the times that
> recordings would start and end in the scheduler output.
I completely understand this. But a global default hard setting would
not help me, nor people in my situation. We'd still need to tweak
settings on a near-daily basis in order to force MythTV to (a) bump
shows to a 2nd or subsequent tuner card, rather than leave it idle, and
(b) fix any new conflicts.
> 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
> or whatever.
> 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
> game show.
I agree with your point here, but in this situation users should be
using a hard setting, and a manual one. I'm not arguing that soft
buffers should replace hard ones. I don't think anybody should rely on a
default soft buffer to capture a show that either they know will run
late, or is so important that they simply must capture extra buffers.
The whole idea with soft buffers is that they're non-essential. You use
them when you're not sure whether you'll need them: when you'd LIKE to
capture extra time, but you don't consider it critical. They work pretty
well for this (unintended) purpose at the moment, with the exception
that they can get dumped while another tuner card sits idle.
Anyway. I'm a little concerned that discussion about the utility of my
patch has turned into a much wide-ranging debate about pre- and post-
buffers, and how nice it would be to have other related features. My
patch doesn't make any big changes in this area, and I hope that devs
can see that it's a small improvement for a minority of users while not
impacting anyone else, and thus worthy of inclusion in the meantime. If
devs wish to add something else further down the track, then terrific,
but it would be a shame to let the possibility of that happening in the
future deny users a small new feature now.
In any case, naturally it's up to the devs whether you want this patch
or not. I can patch my own machine; the only reason I've spent time
going through the submission process is because I'd like to help others
in the same boat. I feel their pain. :)
More information about the mythtv-dev