[mythtv] Re: [PATCH] Soft padding proof of concept

[Max Barry]

David Engel wrote:
 > Would the proponents of adding soft padding to the scheduler please
 > try this patch and provide feedback.  If nobody responds, I'll have
 > to assume it's not really that important after all and consider the
 > whole issue closed.

Thanks for the patch, David. I apologize for not having been able to 
test it yet--life with a newborn isn't leaving much time for anything 
else. I'm also not clever enough to work out from your code exactly what 
it's doing, so can't judge how well it would address my needs.

But I don't want you to think that nobody cares about soft buffers. So, 
after much thought, here's my take on the fundamental differences 
between hard and soft buffers, and why MythTV needs both.

HARD BUFFERS
"You Either Need It Or You Don't."
Use: Informing MythTV of predictable time shifts from guide data.
Appropriate functions:
* Improving the accuracy of guide data. ("If you want the loser's
comments, SURVIVOR runs to 9.01pm, not 9 sharp.")
* Making an allowance for tuner cards that take time to initialize. ("My
card takes 15 seconds to start recording.")

SOFT BUFFERS
"Maybe You Need It, Maybe You Don't."
Use: Insurance against unpredictable timing variations.
Appropriate functions:
* Guarding against unexpected schedule drift ("I'm not confident that
this program will actually be broadcast when the guide data says; I
don't know exactly when it will be.")
* Allowing for clock drift ("I'm not confident that my system clock is
accurate enough.")

I realize this contradicts the established wisdom that soft buffers 
exist in order to allow time for tuner cards to initialize, but I'm 
unable to find the logic in that. If a user has a card that consistently 
takes 15 seconds (or whatever) to initialize, then his system is 
physically incapable of recording 100% of two consecutive shows. It can 
get 99.8% of two consecutive shows, and I understand why for practical 
reasons that's close enough, but the fact remains: he can't do it. What 
devs have decided to do rather than tell him he can't do it, have MythTV 
throw a conflict, and ask him to specify which show he wants to lose 15 
seconds of via priorities, is instead have this soft buffer that lets 
him pretend there's really no conflict at all.

In effect, devs are dividing soft and hard buffers on the basis of how
long they are. You hope that nobody minds too much if they unexpectedly
miss 15 seconds of a show, while if someone misses 5 minutes, you can
say, "Well, you should have used a hard buffer." But what principle is 
this based on? There's no logical point at which an acceptably "short" 
soft buffer becomes an unacceptably "long" one. When there's a knowable 
conflict in advance, users should specify how they want it resolved, not 
leave it to MythTV to make an unexpected decision.

(Getting slightly off-track for a moment: because it would be
impractical to conflict entire shows based on a 15-second overlap,
MythTV should probably handle conflicts better. Could it record the
non-conflicted portion of the lesser-priority show, while still flagging
it in advance as conflicted? This way minor conflicts wouldn't have 
major consequences.)

Soft buffers help with an entirely different situation. When you don't
know reliably in advance exactly when you need to record--and "reliably"
here can mean whatever you want it to; it's up to each user--you're 
faced not with a simple decision about which channel you want MythTV to 
record at a particular point in time, but rather an exercise in 
probability. You want to capture a safety buffer around your programs, 
just in case, but will a minute be enough? Two? Five? You can't know for 
sure. In contrast to the situations for which hard buffers are 
appropriate, you're not entering a number that carries a great deal of 
precision; all you can do is guess. You just try to balance the risk of 
missing a program that runs really late versus the waste of recording a 
buffer that you end up not needing, and thus unnecessarily consuming 
disk space and tuner time.

Because the soft buffer is "just in case," you want MythTV to dump it 
rather than miss recording other shows. Of course, you'd prefer it 
always captured the soft buffer, but if we're looking at a conflict 
situation, then you don't have enough tuner cards to grant all your 
wishes, so you can't have everything. Soft buffers must inherently be 
risky, because their purpose is to deal with uncertainty. They merely 
help you stack the odds; they do not, cannot, and should not guarantee 
anything.

When you force users to use hard buffers in situations where soft
buffers are more appropriate, you're making us continually and manually 
work out how busy or free MythTV is at various times, and thus whether 
it's worth adding or removing a safety buffer around programs--a task 
that MythTV itself is much more easily able to perform. Furthermore, you 
ask us to pretend that there's a precise buffer number which we consider 
it essential to capture every second of, even if it means missing other 
shows, and after which we don't want a single second of, even if MythTV 
is completely idle. That's not the reality, and why hard buffers are a 
poor substitute when it comes to dealing with uncertainty.

Max.