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

Max Barry 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 
it'll be.

>>  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
> value.

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 
anyone else.

>> 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
> solution.

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 
any show.

> 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

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 mailing list