[mythtv-users] Mythtv .19 live watching

Michael T. Dean mtdean at thirdcontact.com
Thu Jul 13 07:49:57 UTC 2006


On 07/13/2006 02:55 AM, chris at cpr.homelinux.net wrote:
> On Wed, Jul 12, 2006 at 01:23:07PM -0400, Michael T. Dean wrote:
>   
>>   At that point, Myth could break the current 
>> program and let autoexpire delete that portion.  But, that's a lot of 
>> logic to write for a "just-in-case"...  And, if the person watching the 
>> show later decides it's worth keeping, they lose the entire beginning, 
>> so it's not an ideal solution...
>>     
>
> The ideal solution is one that conforms with user expectations, not 
> one that's easier to program.  
>
> Programs that use ring-buffers traditionally have two ways of 
> dealing with buffer overflows: if the data is not important then 
> you eat your own tail; if the data is important then Something Bad 
> Has Happened and the program should treat the overflow as a 
> critical error.  Dealing with that critical error is then a 
> completely separate issue.  Using a dynamic buffer doesn't change 
> the choice of outcomes -- it simply delays the buffer-full 
> condition.
>
> AFAIAC, the live TV buffer is not a "recording" until the user 
> manually chooses to make it one.  That would make the ring-buffer 
> contents non-critical, and the only reasonable course of action 
> would be to eat your tail.  In the case of a dynamic buffer, you 
> can allocate more and more storage to delay eating your tail, but 
> at some point you have to be prepared to do it.  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.

>   The fact that 
> segmenting the recording to facilitate eating your tail is 
> difficult doesn't mean it shouldn't be done.

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

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.

>   If anything, it 
> should be done early and often, because you don't know what other 
> programs are going to allocate or free up space concurrently with 
> the live TV buffer.  In other words, you should be ready to eat 
> your tail at any time in order to make room for other applications 
> (including other MythTV recordings).
>
> When the user decided to convert the buffer into a recording then a 
> whole different set of rules applies.  Now it's reasonable to start 
> expiring old programs to make room.  Now a buffer-full condition 
> becomes critical because it means that you have no disk space left 
> AND no programs left to expire.  At that point I would expect the 
> recording to stop, and the movie/episode marked for re-record.  
> Freeing up storage is then the user's responsibility.
>
> I rarely use live TV in Myth, but would be very upset if MythTV 
> started deleting real recordings to make room for an 
> infinitely-expanding ring-buffer.  That would be like Microsoft 
> Windows killing FireFox to free up memory for Excel -- it's not 
> what the user expects, and more importantly it usurps the user's 
> authority.

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.  If part of the current recording has already 
autoexpired, then the user ends up with only part of a recording (a la 
0.18).  And, the user never gave Myth permission to do any of this...

In my mind, the user's entering LiveTV is explicitly giving Myth 
permission to record the current program on the current channel.  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.

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.

Mike




More information about the mythtv-users mailing list