[mythtv-users] Mythtv .19 live watching

[Richard Freeman]

Michael T. Dean wrote:
> 
> 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.
> 

A bit off-topic on this thread, but a text-based setup tool would be
useful.  There is really no need to have a GUI for mythtv-setup, and in
fact it doesn't even use the mouse anyway.  However, I'm sure most
people would feel that this is not the highest-priority issue out there
right now.

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


Actually, assuming that somebody is watching LiveTV isn't really
reasonable considering how easy it is to turn off the TV without hitting
ESC/Back/whatever.  Happens all the time in my house, despite occasional
reminders to the kids - and it isn't like I want to nag them about it
every 5 minutes when there are more important things to nag them about
like not leaving the door open with the AC on.

The way most DVRs handle LiveTV conflicts is with a pop-up prompt
stating that the system is going to do some action in x minutes and to
confirm/prevent this action with a response (which defaults to stopping
liveTV in the assumption that nobody is watching it if there is no
response).

Most of my shows are set to autoexpire - and if the system deleted a few
of them to record some show that had higher priority then it is just
doing what I wanted it to do.  On the other hand, if one of the kids
leaves the TV on liveTV mode on some channel with a high bitrate and a
long program and the system wipes out 60% of the recorded shows that
would not be the correct behavior.  Sure, I don't mind those shows being
deleted per-se, but that was with the expectation that when I sit down
to watch TV I'd have something else to watch, not a 2/3rds blank disk
(since as soon as that 12-hour show ended it would probably get deleted
anyway).

Sure, this is easily fixed by having $50 worth of unused hard drive
sitting around, but if I did have extra space I'd rather be using it
than buffering against a minor design flaw.

Granted, in most cases this bug isn't a huge deal unless you have some
very-long programming on a high-bitrate channel.  With high-def that
could happen, and 300GB drives are expensive enough that I'd rather not
own one just to leave it unused just-in-case.

BTW - I just have to comment that I love MythTV - beats the socks off of
the DirecTV R15 DVR that was driving me insane before I took the plunge
(design isn't bad, but implementation is horrible).  I look at issues
like this as things that should be acknowledged as needing a better
solution, but when it comes to priority I wouldn't consider this at the
top of the list.  By simply acknowledging that a better design might
exist you at least open yourself up to improving the design when other
changes need to be made anyway, or when some of the higher-priority
issues are resolved.

Maybe a possible configuration item would be a
non-technical-users-present page which lets you easily turn on some
settings designed to compensate for users who do not fully appreciate
the design of the system.  Another family-friendly option would be to
have user groups / permissions so that a kid or guest can't cancel a
recording show in order to watch liveTV if the show that is recording is
particularly important.  It might also be nice if the system could keep
track of who has seen a particular show in case more than one person
wants to see it and they don't always watch TV together.

The nice thing about mythtv is the fact that there is a community, and
the community's voice actually impacts the design.  I for one would like
to acknowledge that the current developers have clearly been listening!
 I would also encourage the devs to recognize non-ideal cases in the
design even if they are a pain to fix - not so that they can be harped
on or fixed immediately, but rather so that they can be kept in mind so
that eventually they might be fixed in a creative way, or the next time
there is a significant rewrite/redesign anyway.  On most software design
projects of some size a list of known defects/change-requests is
maintained even if 90% of them will never be fixed - because if a dev is
going to tear apart some module they might as well fix the bugs while
they are there.