[mythtv-users] Mythtv .19 live watching
chris at cpr.homelinux.net
chris at cpr.homelinux.net
Thu Jul 13 18:25:56 UTC 2006
On Thu, Jul 13, 2006 at 03:49:57AM -0400, Michael T. Dean wrote:
> > AFAIAC, the live TV buffer is not a "recording" until the user
> > manually chooses to make it one.
> > If you run out of
> > storage before the user selects "record" then that's *the user's
> > problem* for not selecting "record" earlier.
>
> I thought we were designing it to meet user expectations... Sounds like
> the user who pushed TOGGLERECORD too late expected it would still work.
It's an unreasonable expectation. If it takes someone more than an
hour to decide whether or not a show is worth capturing then the
show is probably not valuable enough to cause prerecorded shows to
be deleted. Think of it this way: people compare MythTV and Tivo
to a VCR. If you start recording on a VCR at 5 minutes past the
hour then you missed the first 5 minutes and are stupid for not
planning ahead. If you reach the end of the tape before the show
is over then you lose the ending and again are stupid for not
planning ahead. If the VCR was to magically pull another tape off
the shelf and record over it, people would be stampeding to the
stores to return the VCR because the decision to destroy other
property is indefensible. MythTV has the advantage of a buffer so
the user can start recording after watching a bit of the show, but
it's not reasonable to destroy existing data in order to allow them
to waffle for the first 119 minutes of a two-hour program.
> The fact that it's never a problem if:
> a) You don't leave LiveTV running on a channel with a program that's
> extremely long.
> b) You have enough space available for the longest program in your
> listings.
Auto-expire would never happen if people always had enough disk
space left. The point is that it happens and it should be dealt
with in a rational way, not a lazy way. As I mentioned before,
there could have been enough disk space when you started the
recording but other programs have created large files since then.
The problem of low disk space needs to be handled regardless of how
it comes to pass. A properly designed out-of-storage manager
wouldn't care if the cause was a fringe case or something
entirely predictable.
Blaming the user for his mistakes is OK. Blaming the user for the
effects of your design decisions is not.
> c) You explicitly tell Myth to insert a break (with a channel change
> during a commercial or by exiting and re-entering LiveTV or ...)
> or
> d) You never use LiveTV ;)
My choice (currently) is "d", but that has less to do with the
current bad design and more to do with the fact that I prefer to
time-shift the shows I know I want and don't have a lot of interest
in pausing live TV. For me the issue may be a latent defect rather
than an active one, but it still represents a risk to my recordings.
> means (to me) that writing a lot of code for this fringe case is not
> worthwhile. Thus, I won't write any code for it. :) If someone else
> wants to write the code, please feel free to do so.
One of the things about design decisions is that when you do things
the right way then later features become easier and easier to add,
whereas when you do things the lazy way you paint yourself into a
corner and things get harder and harder until eventually you have
to refactor the code because progress becomes impossible. This
isn't about working around the "fringe case". It's about the fact
that the design decision here is just plain wrong because it
creates so many fringes in the first place. Getting the design
right means you spend less time worrying about fringe cases
(because there are fewer of them) and have a more sensible platform
for later work.
As far as writing code goes - if I had gobs of spare time I would
fork the project completely because the recording buffer is not the
only place where design has taken a back seat to expediency. The
GUI is still an abomination. The mythtv-setup program shouldn't
even exist, or should at least be text-based so that the back-end
can be installed on a machine with no X11 and no monitor.
You should read Eric Raymond's commentary on the CUPS system
entitled "The Luxury of Ignorance: An Open-Source Horror Story"
<http://www.catb.org/~esr/writings/cups-horror.html>. Most of his
observations are so spot-on he could have been writing about
MythTV. Robert Cringely has made similar comments about the
success of Apple as well.
> Wouldn't breaking up a LiveTV recording usurp the user's authority? If
> the user decides to save the show (hits TOGGLERECORD) after the break,
> then he/she is only saving the part after the break. So, if there's
> code to move all parts from LiveTV (assuming previous parts haven't
> autoexpired, already) then the user ends up with more than one file for
> the one recording.
The decisions about what to do when the user chooses to record a
show belong in the "what should I do when the user selects record?"
category, not the "how much valuable data should I delete on spec
just in case the user selects record later on?" category. As I
said in my previous email, I don't think live TV is the same as a
recording and therefore the live TV buffer is expendable. Grow the
buffer as much as you want, but be prepared to eat it if disk space
gets too low.
I would think it's obvious that when the user selects "record" then
the fragments should be gathered and logically (if not physically)
concatenated. It doesn't matter whether you are breaking on the
hour or every 5 minutes. Once you have code that can join the
fragments it doesn't matter how short those fragments become. The
code that converts a live buffer into a recording should SERVE the
disparate needs of the live TV and recording management modules,
not define how they will work. Once you adopt that mode of
managing the spool files then you can actually consider doing
things like gathering the fragments that came before and after the
user went channel-hopping during a commercial. If the schedule showed a
2-hour program and you found 23 5-minute fragments then it's better to
keep those than to use a 1-hour cut-off and lose half the show or (worse
yet) create two one-hour entries in the recordings directory.
When the user selects "record" you could use the schedule to figure
out what to keep, or you could keep everything for the current
channel and let them edit out what they don't want, or you could
ask them for start/stop times.
> In my mind, the user's entering LiveTV is explicitly giving Myth
> permission to record the current program on the current channel.
And I respectfully disagree. In fact, didn't 0.18 cancel live TV
if a scheduled recording was about to start (unless you explicitly
told it to continue)? There was an assumption that live TV was a
lower priority than the scheduled recordings, and that priority has
now apparently been inverted.
Maybe the question of whether live TV is a higher or lower priority
than the scheduled recordings should be settled by explicitly
assigning it a recording priority and then comparing it to the
scheduled events. Furthermore, if the auto-expire was done on the
basis of the recording priority instead of just age then live TV
could delete last night's "Simpsons" (which will be on five more
times in the next three days) while leaving last week's "House"
even though both are able to be expired.
When you think about it, a show's priority is a good indicator of
whether or not it should be allowed to auto-expire, and can also be used
as a hint for the "reschedule higher priorities" option. Both of those
options could be eliminated entirely if the priorities were tiered. For
example:
> 100 don't expire; don't reschedule for lower priority
50 to 99 don't expire
1 to 49 expire last; mark for re-record
0 live TV buffer
-1 to -49 expire when required; mark for re-record
-50 to -99 expire first; can't bump higher priority; don't re-record
< -100 don't record (immediately moved to "previously viewed")
This would mean retaining the priority even after the show had been
recorded. The toggle for whether or not to flag a show for
auto-expire would simply change the stored priority value. Expiry
would be done by priority value, and dates would only be used when
two or more shows with the same priority made it to the bottom of the
priority list.
What it boils down to is that if you think the user wants you to
take a destructive action, don't assume. A reasonable design would
try to minimize the damage, both by confirming the user really
intends to destroy existing data and then by doing so in a more
intelligent way.
> If
> that user is short on space, starting a new recording is explicitly
> giving Myth permission to autoexpire old recordings, as necessary.
> Therefore, I see this as doing exactly what the user asked.
This is a destructive assumption.
> Now, whether the user meant to ask that (as opposed to the dog stepping
> on the key bound to the LiveTV jump point or the kids getting bored with
> the commercials-laden LiveTV and walking away or ...) is a whole other
> question... But, in those cases, simply having enough storage space
> solves the problem.
The kids walking away or the dog stepping on the keyboard are only
problems because the design assumptions make them into problems. I
get your point -- "stuff happens" -- but a robust application
shouldn't even see most of that "stuff" as problems.
More information about the mythtv-users
mailing list