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.
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
