[mythtv-users] Mythtv .19 live watching

[Michael T. Dean]

On 07/14/06 03:52, Osma Ahvenlampi wrote:

>On to, 2006-07-13 at 15:40 -0400, Michael T. Dean wrote:
>  
>
>>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).
>>    
>>
>Where did you got that infinite capacity storage system you obviously
>use?
>  
>

It hardly needs to be infinite capacity--and that's the entire point.  
It simply needs to be sufficient capacity to hold the longest program in 
the listings:

mysql> SELECT MAX(SEC_TO_TIME(UNIX_TIMESTAMP(endtime) - 
UNIX_TIMESTAMP(starttime))) AS 'Max Duration' FROM program;
+--------------+
| Max Duration |
+--------------+
| 06:30:00     |
+--------------+
1 row in set (0.07 sec)

So, given my average recording size of 1.15GiB/hr, that means I simply 
need to have 7.5GiB free to record /any/ (or all) LiveTV show(s).

Even if I used a ridiculously-high bitrate (instead of my 
ridiculously-low bitrate of 2.75kbps (including audio)) like 9800kbps 
(the max allowable by the DVD spec), that 6.5hr show is still less than 
27GiB.  And, how much is a 300GB HDD?  ( 
http://www.newegg.com/ProductSort/SubCategory.asp?SubCategory=14 )

>>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 
>>    
>>
>You're making a rationalization of a coding choice post-fact. Consider
>that:
>
>* If someone has exclicitly asked for a program to be recorded, it
>obviously is (or at least was, but the system doesn't know the
>difference) important to her, even (especially) if still unwatched. Not
>all users have all the time in the world to watch everything
>immediately, that's what a DVR is for.
>  
>

I would argue that if she's currently watching LiveTV (= whatever is on 
right now)--as opposed to a show that she recorded because it was 
important for her to be able to watch it--she's run out of interesting 
recordings to watch, so the LiveTV must be more important to her than 
the recordings.

>* Most, if not all recordings must be marked autoexpire, otherwise every
>system will run out of space eventually. It's unreasonable to expect an
>end user to manage the storage by deleting things manually. Again, a
>DVR's function is to make life easier for its user, not to introduce
>something new to manage.
>  
>

Right, so important recordings should be marked to not autoexpire.  
Then, when the user is ready to delete them, he/she can do so or can 
simply mark them as eligible to autoexpire.

>* A LiveTV program can be reasonably assumed to be watched by someone,
>as you state yourself. That implies it has been seen (to the point where
>it's been broadcast, minus time-shift delay). That makes it less
>important than an auto-expire, unseen previous recording.
>
>Now, MythTV DOES make all of these assumptions, since it prioritizes
>LiveTV buffers lower than recordings. It's just that it doesn't do that
>completely, and due to unimplemented cases, leads to situations where it
>does the wrong thing based on the above observations, which are its own
>design assumptions.
>
>>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.
>>    
>>
>As stated above, no reasonable end user wants to have more stuff to
>manage. In fact, you don't want to either. If the system made the right
>decisions by itself, you'd be happy to let it make those decisions and
>would have no need to manage the expiration process yourself.
>  
>

Oh, I think I see what you want now.  You want to mark all recordings as 
eligible for autoexpiring (so you don't have to explicitly mark them 
once you're done with them), but you want Myth to only delete those 
recordings that you want to delete.  Hmmm.  See if you can work up some 
code to do that.  I'm sure it would be accepted.  :)

>>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.
>>    
>>
>That is a perfectly valid assumption. The implementation however
>additionally assumes that what was on LiveTV three hours ago and was
>already seen is ALSO more important than a previously recorded program
>if the channel guide (which the user has no control over) didn't have a
>program change in between. This is the not-perfectly-reasonable
>assumption that the thread is having problems with.
>

It all comes down to atomicity.  It seems our definitions disagree, though.

>>Hmmm.  You mean like creating a setting:
>>
>I can't presume to know what Chris meant, but please, no more settings!
>

No need to create a new setting for "Auto Expire Method."  :)  (/me 
chuckles)

Mike