[mythtv-users] Mythtv .19 live watching

[Osma Ahvenlampi]

On pe, 2006-07-14 at 04:53 -0400, Michael T. Dean wrote:
> On 07/14/06 03:52, Osma Ahvenlampi wrote:
> >* 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
>
> 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.

Could be that we're talking of two users here. The mom might have an
important program recorded that she simply hasn't had time to watch, and
the children like to leave live tv on for hours and hours. On a channel
that has no useful program guide information.

> >It's unreasonable to expect an end user to manage the storage
>
> 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.

"Users should not be required to manage the system". "Right, so, we have
this system by which they can manage the system".

What's wrong with this dialogue?

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

I'm sure you thought you were being really funny. This is serious,
though.

It's reasonable to state to the user that recordings will be expired in
the order they were recorded. That sets a very simple to understand
expectation as to what will happen.

It's also reasonable to state that recordings will be expired in the
order they were watched. It's a little more difficult to keep track of,
but not conceptually hard to understand.

It would ALSO be reasonable to choose either one of those, and extend
that logic by stating that any recording which has explicitly marked as
"I want to archive this one" would not be expired.

Introducing prioritization into the picture is "interesting", but makes
the system fairly complex. As such prioritization does exist for
recording, it might be feasible to find a balanced scoring algorithm
that takes both the age, watched/not watched, and recording priority
into account and makes expiry choices based on that. It will be nearly
impossible to explain that logic in documentation, but provided it was
made sufficient clear in the UI (ie, not hidden in a "System status"
menu, but perhaps displayed in the Schedule recordings view in a small
area labeled as "to make room for more recordings, these three shows
will be deleted next" and provide an option to delay the expiry on any
one of them), perhaps that could be made to work. I wouldn't go there,
personally, though.

What's not reasonable is to expect the system to continue to work well
in a situation where nothing can be expired. To overcome this, I would
introduce some kind of "wizard" that would ask the user to resolve the
situation if more that (say) 75% of storage is taken by unexpirable
content and more is scheduled for recording. Such a wizard should either
make it simple to find shows that probably don't need to be marked
unexpirable (because they've been seen already, or something), or shows
that might be candidate for archival to removable media (old stuff that
hasn't been watched recently, for some definition of "recent" based on
average age of the content). This would probably be the logical location
for MythBurn functionality.

> >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  didn't have
> >a program change in between.
> 
> It all comes down to atomicity.  It seems our definitions disagree, though.

By atomicity I take it you're referring to the "longest unit in program
guide". We can probably agree that the length of that unit a) varies by
region/sources b) is not predictable and c) can not be controlled by the
user. My argument basically is that the design must take these facts
into account, and that there does not have to be relation between the
unit lenght in the program guide and live tv file buffers, as they could
be merged together either by the recording backend or the
display/playback code and presented to the user as a single logical unit
anyway.

Sure, it's a more complex implementation. But that's what software is
for - to provide complex functions to users under an easy interface.

Well, I'm off to a vacation, finally. Hoping my installation keeps
recording what I want it to - at least it won't have to cope with live
tv in the meantime. To be fair, most if not all of my recent problems
have been due to hardware, not the application.

-- 
Osma Ahvenlampi   <oa at iki.fi>    http://www.fishpool.org