[mythtv-users] Mythtv .19 live watching

[Michael T. Dean]

On 07/13/06 14:25, chris at cpr.homelinux.net wrote:

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

To you.  Recording without deleting when short on space is an 
unreasonable expectation to me.

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

Which is why Myth allows the user to specify the amount of space 
reserved for other programs...

Extra Disk Space (in Gigabytes)
Extra disk space you want on the recording file system beyond what 
MythTV requires. This is useful if you use the recording file system for 
data other than MythTV recordings.

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

It's not a risk to my recordings.  I have enough space to handle any 
LiveTV recording (and my system doesn't record LiveTV when no one is 
watching it, anyway).

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

Interesting how the guy preaching about how lazy the MythTV developers 
are doesn't have time to fix any problems.  I guess you're just saying 
your time is more valuable than Isaac's, et. al, and they should get 
right on fixing this problem for you.

Perhaps you should look up the guy who re-implemented MythTV in just a 
few lines of Perl code.  Even if he completely missed the boat (and 
created an abomination as bad as MythTV), there's a lot less code to fix.

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

Not going to make a comment about the importance of 150MiB (installed 
size of X and less than 10 minutes of a recording at 2000kbps or 
5min at 4000kbps or 2.5min at 6000kbps) to a backend.  Not going to comment on 
the backend's not needing a monitor (or even needing to run an X 
server).  Not going to comment on the fact that Qt3 makes installation 
of X mandatory, anyway, and that Myth requires Qt3.

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

I have.  And, while I generally respect ESR's opinions, I feel that 
essay is just plain wrong.  He talks about the usability of CUPS based 
on the GUI configuration tools provided by Fedora Core (not by CUPS).  I 
might as well say that Linux is poorly designed because I used "Bob's 
Bad Linux" and found it difficult to configure it.  (Every distro is so 
different that they might as well be considered different operating 
systems.  I cannot use any of the distros effectively, but I know a bit 
about GNU/Linux--I have never been unable to configure my GNU/Linux 
systems to do something I wanted them to do and they do a lot for me.)  
Now, if he properly attributed the blame to Red Hat, I might take it 
more seriously, but even then, IMHO, the FC configuration tools (or any 
other distro-specific config/GUI tools) are not a good indicator of the 
way open-source design generally works (for various reasons I won't go 
into here), and, regardless, he's confusing responsibilities (but that's 
a whole different story).

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

And that's where the distinction comes in.  MythTV currently assumes 
that the currently-recording LiveTV show (which, by all reasonable 
assumptions, someone is watching) is more valuable than some old 
previously recorded show.  If you haven't yet watched the old 
recording--which you (the user) explicitly marked as eligible to 
autoexpire (thereby giving Myth permission to delete it)--who's to say 
you will.

If you don't want the show to autoexpire, don't mark it eligible to 
autoexpire.  Once you watch it, then mark it to allow autoexpire.

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

No.  There hasn't been a change in assumptions.  The assumption is that 
what's on LiveTV now (a show that someone is watching) is more important 
than some old /previously-recorded/ program that the user may or may not 
have gotten around to watching.  IMHO, that's a perfectly valid assumption.

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

Hmmm.  You mean like creating a setting:

Auto Expire Method
    - Oldest Show First
    - Lowest Priority First
    - Weighted Time/Priority Combination
Method used to determine which recorded shows to delete first.  LiveTV 
recordings will always expire before normal recordings.

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

If only that setting existed in frontend settings in the General section 
on the page "General (Basic)"...

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

Encoding additional meaning into priority?  Yeah.  That's intuitive.  
 From ESR's essay that you quoted, "Rule 1 of writing software for 
nontechnical users is this: if they have to read documentation to use it 
you designed it wrong."

Anyway, you don't have to convince me.  I /will not/ write any code for 
this case.  Perhaps your arguments were enough to convince one of the 
devs or another user to write some code.

Mike