[mythtv-users] My experience with MythTV annoyances

[Yeechang Lee]

Boleslaw Ciesielski <bolek-mythtv at curl.com> says:
> If this patch gets in, the recommendation against ext3 may be the thing
> of the past:
> 
> http://svn.mythtv.org/trac/ticket/1835

Thank you, thank you, for the feature add! Funny you mention it,
because I tried your patch (to be accurate, the 10K "reviewed but
untested" version) out yesterday. Applied cleanly to my 0.19-fixes
(ATrpms) system, which surprised me as I figured it'd only work on the
latest SVN. However, here's how the truncations occur:

a) the file gets renamed to 'cifsxxxx', which I think is some kind of
   temporary name the filesystem (mounted over cifs, naturally) uses
   while it's working on it.
b) The truncations are really, really slow. Like, 35KB (not MB) per
   second slow. Initially, the backend told me (after restarting it
   with --verbose important,general,file):

    Truncating '/misc/cube/mythtv/store/1170_20060611234200.mpg' by 0.07
    MB every 500 milliseconds

Now, I have three HD capture streams which together can theoretically
generate 7.27MB/second of data. Adding a slave backend which, when
lossless transcoding, can probably generate another 2.42MB worth,
results in a total of 9.7MB. Given your 20% margin, we need to
truncate 12MB/second, not 0.14MB/second. But I wasn't even getting
*that* level of performance.

I thus tried changing

increment = (expirer->GetMinTruncateRate() * sleep_time + 999) / 1000;

to 

increment = (expirer->GetMinTruncateRate() * sleep_time + 999) / 1;

And now got

    Truncating '/misc/cube/mythtv/store/1170_20060612001346.mpg' by 66.76
    MB every 500 milliseconds

But still the 35K/second truncations. My theory is that trying to do
two truncations a second, regardless of size, is overwhelming the NAS
and its filesystem. I suspect that longer intervals--say, truncating
120MB every 10 seconds--will be more efficient.

-- 
Yeechang Lee <ylee at pobox.com> | +1 650 776 7763 | San Francisco CA US