[mythtv-users] Mythtv .19 live watching

Osma Ahvenlampi oa at iki.fi
Fri Jul 14 07:52:07 UTC 2006


On to, 2006-07-13 at 15:40 -0400, Michael T. Dean wrote:
> 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:
> >>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.

Now this is just silly. You can not record when there is no space.
That's a constraint, not an assumption. Please try to think of
objective, assumption, constraint and design choice separately from each
other, you'll find it helps model the system better.

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

Actually, MythTV doesn't "allow" these - it requires these, as it does a
whole lot of other unreasonably complicated settings that create all
sorts of weird, unworkable combinations. I would venture to state that
for most of these cases, the existence of the setting is due to laziness
on the part of the designer.

Oops, sorry, there's no design here, just code. Anyone volunteering to
offer a design is shot down unless they volunteer the code at the same
time. (okay, rant off. sorry about that)

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

LiveTV is not a problem for me either, because I never, ever use it. I
learnt ages ago that it's far more reliable to schedule a recording and
watch it time-delayed than to try and trust LiveTV, even if it would
have been more convenient. Doesn't this tell you something about a
design problem?

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

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

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

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

> Hmmm.  You mean like creating a setting:

I can't presume to know what Chris meant, but please, no more settings!

"It turns out that preferences have a cost. Of course, some preferences
also have important benefits - and can be crucial interface features.
But each one has a price, and you have to carefully consider its value.
Many users and developers don't understand this, and end up with a lot
of cost and little value for their preferences dollar."

-- Havoc Pennington, http://ometer.com/free-software-ui.html

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



More information about the mythtv-users mailing list