[mythtv-users] Playback of recordings ends a short way into them

[Richard Townsend]

> On Nov 12, 2014, at 6:15 AM, Rich Freeman <r-mythtv at thefreemanclan.net> wrote:
> 
> On Wed, Nov 12, 2014 at 1:37 AM, Richard Townsend
> <townsend at astro.wisc.edu> wrote:
>> 2014-11-11 23:37:15.747353 E [2187/4174] HDHRStreamHandler threadedfilewriter.cpp:239
>> (Write) - TFW(/mnt/mythtv/tv/1571_20141112053000.mpg:68): Maximum buffer size exceeded.
>>                        file will be truncated, no further writing will be done.
>>                        This generally indicates your disk performance
>>                        is insufficient to deal with the number of on-going
>>                        recordings, or you have a disk failure.
>> 2014-11-11 23:40:09.661866 W [2187/4171] TFWWrite threadedfilewriter.cpp:571 (DiskLoop) -
>> TFW(/mnt/mythtv/tv/1571_20141112053000.mpg:68): write(58092) cnt 1149 total 67108856
>> -- took a long time, 231384 ms
>> 
>> I’ve been trying to see if my NFS performance is a bottleneck,
>> but it doesn’t seem to be. Is this possibly an issue with the HD
>> HomeRun?
>> 
> 
> I used to have that kind of problem all the time with multi-disk
> arrays and multiple recordings.  I found that disabling mythtv's fsync
> calls and increasing the buffer size fixed the problem for me. I did
> have a conversation with a developer a while ago and they indicated
> that this change could be problematic, so they wouldn't recommend it
> for general use.
> 
> Writes to RAID tend to be happier with larger write sizes and longer
> latencies, since the bandwidth of all those drives is high, but the
> cost to seek them all is also high.  I think that all those fsync
> calls basically kill the write cache and make it harder for the kernel
> to manage the IO queue.  On the other hand, the mythtv devs put in the
> fsync calls because their experience was that the kernel doesn't do
> such a great job with the queue anyway.
> 
> I also run my mythbackend process with realtime IO scheduling class.
> 
> If you want to try it, here is my patch, but you're probably on your
> own with this one:
> 
> --- mythtv/libs/libmythbase/threadedfilewriter.cpp.orig 2014-03-21
> 18:21:22.067061254 -0400
> +++ mythtv/libs/libmythbase/threadedfilewriter.cpp      2014-03-21
> 18:21:47.325630103 -0400
> @@ -41,7 +41,7 @@ void TFWSyncThread::run(void)
>     RunEpilog();
> }
> 
> -const uint ThreadedFileWriter::kMaxBufferSize   = 8 * 1024 * 1024;
> +const uint ThreadedFileWriter::kMaxBufferSize   = 64 * 1024 * 1024;
> const uint ThreadedFileWriter::kMinWriteSize    = 64 * 1024;
> const uint ThreadedFileWriter::kMaxBlockSize    = 1 * 1024 * 1024;
> 
> @@ -382,9 +382,9 @@ void ThreadedFileWriter::Sync(void)
>         // fdatasync tries to avoid updating metadata, but will in
>         // practice always update metadata if any data is written
>         // as the file will usually have grown.
> -        fdatasync(fd);
> +//        fdatasync(fd);
> #else
> -        fsync(fd);
> +//        fsync(fd);
> #endif
>     }
> }

Thanks for the suggestion. In fact, it turned out that the transfer rate to my NFS-mounted NAS was the culprit — for some yet-to-be-ascertained reason, it’s severely impaired right now, which is in turn causing problems for myth.

Thanks to all who responded.

cheers,

Rich