[mythtv-users] MythTV Installer Usability: An Analysis

[Ant Daniel]

On 11/4/05, f-myth-users at media.mit.edu <f-myth-users at media.mit.edu> wrote:
>
> Date: Fri, 04 Nov 2005 18:32:51 +1000
> From: ffrr <ffrr at tpg.com.au>
>
> Is this because the ringbuffer file seems to continually grow? I have
> noticed this. Why does it do that? If you are not paused, surely the
> file size should remain stable?
>
> Yes. The ringbuffer grows monotonically -up to its configured limit-
> and then (I assume!) stops growing. It's not clear to me why the
> installer defaults to a partition sufficient to hold 5.3 hours' worth
> for a 200GB disk, though; that seems like an awfully large buffer.
> (I've cursed my TiVo's half-hour buffer, but it's seemed to me like
> a couple of hours should be plenty. Maybe it's 'cause Myth doesn't
> allow you to dump the ringbuffer into an active recording [e.g., you
> see something on TV you didn't know would be on, and decide you want
> to save the entire thing, including what's already been aired], and
> without this capability you tend to need a much larger ringbuffer?
> I dunno. I -do- hope that this capability is added someday; it's
> been a real lifesaver on my TiVo.)
>
> The problem is that the eventual upper bound of the ringbuffer, at
> least with the sizes I got by default (and, apparently some others
> in the KnoppMyth forum) is a couple GB -larger- than the size of the
> partition the installer allocated for it, and Myth handles this...
>
> ...poorly.
>
> To say the least.
>
> Obviously, the two halves of the installer need to talk to each other,
> to the pick the right sizes, or at least the ringbuffer-defining half
> needs to actually look at the damned partition and make the intelligent
> guess that (a) its default should not be bigger, and (b) the user
> should not be allowed to -make- it any bigger, either.
>
> In the current case, the installer defaults to behavior that will
> cause the machine to livelock and explode if the user has the bad
> luck to leave the UI on the wrong screen and go to bed. Whoops.
>
> P.S. The current installer's default of such a large ringbuffer and
> ext2 (ext3?) also has the problem that trying to switch away from live
> TV back into the UI can take a -very- long time---apparently the
> ringbuffer is deleted immediately (hey! but what if I wanted to finish
> watching something after doing something in the UI! now it's -gone-!),
> but deleting 12GB in that filesystem takes something like a second per
> GB, at least, even on fast hardware, because of all the disk thrashing
> that's required. The first time this happened to me (while testing
> the above behavior), I was wondering if the machine was -again- wedged,
> until the UI finally reappeared. Other filesystems (XFS? JFS? I don't
> remember) are apparently much faster to delete, although using those
> for the ringbuffer now means the kernel & installer need to know about
> more filesystems & have tools to manipulate them, etc etc, more
> complexity, yadda yadda... Easy enough for a custom install;
> questionable (maybe) for something like KnoppMyth. I'd be happy
> to be proven wrong.
>
> (And, y'know, I've deleted very large files on identical hardware and
> didn't seem to wait so long. Either the uncertainty was making it
> feel like forever, or Myth is doing something -else- weird while
> that's going on which is making the whole process take even longer.
> Maybe I'll set up another test someday, but not tonight.)
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>
>
Even though the installer sets an incorrect size, really Mythtv should
detect a full disk state and handle it appropriatly. What if (as I have) you
have your ring buffer on the same drive as your recordings, in this case the
size available to the ring buffer could be less than the it's set size, (if
you have many outstanding recordings).
 I thought there was some tuning settings for this, but maybe I'm just
thinking of the auto-expire stuff.
 However there is work being (going to be) carried out on the whole
ringbuffer system http://svn.mythtv.org/trac/ticket/340 so that might effect
some of the useability problems (although a disk full event might still not
be trapped).
 Ant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20051104/06cc506f/attachment-0001.htm