[mythtv-users] Mythtv .19 live watching

[chris at cpr.homelinux.net]

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.