[mythtv-users] truncated recording

[Mark Wedel]

On 02/17/14 07:42 PM, George Mari wrote:
>
> On 2/17/14, 8:40 PM, Mark Wedel wrote:
>> On 02/17/14 03:30 AM, Mike Perkins wrote:
>>> On 17/02/14 02:45, Mark Wedel wrote:
>>>>
>>>>   A few nights ago, my recording of OTA olympic recording was truncated.  It
>>>> would end after about 15 minutes.
>>>>
>>>>   Since I started watching it while it was still on, mythtv was claiming the
>>>> space used was increasing, and after it finished recording, statedthe recorded
>>>> size was about 25 GB.
>>>>
>>>>   However, using the info to find out the file name, and then finding the
>>>> actual
>>>> file in the filesystem, it was about 1 GB.  Mythtv itself did not state any
>>>> errors with the recording.
>>>>
> [deleted]
>>  There are no errors in the log messages or anything else to indicate a disk
>> problem, though that isn't to say that might not be the cause.
>>
>>  But in that case, I would expect that mythtv would see an error writing the
>> data out, and thus not presume the file was recorded OK. Mythtv clearly
>> believed it was writing out data, yet the file itself does not reflect that.
> [deleted]
>
> I know you said you didn't find any errors in the log files, but this sounds
> exactly like the problem I've been trying to resolve on my system the last
> couple of weeks.  In my case it's not exactly a disk problem, but a disk system
> performance problem.  It's very clearly spelled out in the error messages stored
> in the logs - I usually get several of these messages:
>
> Feb  9 03:26:26 poseidon mythbackend[2644]: 2014-02-09 03:26:26.416829 W
> TFW(/video/recordings/2051_20140209060000.mpg:83): write(65424) cnt 63 total
> 3851744 -- took a long time, 2936 ms
> Feb  9 03:26:31 poseidon mythbackend[2644]: 2014-02-09 03:26:31.448490 W
> TFW(/video/recordings/2051_20140209060000.mpg:83): write(12408) cnt 45 total
> 2815864 -- took a long time, 1484 ms
> Feb  9 03:26:42 poseidon mythbackend[2644]: 2014-02-09 03:26:42.383568 W
> TFW(/video/recordings/2051_20140209060000.mpg:83): write(46248) cnt 80 total
> 4935940 -- took a long time, 2503 ms
>
> ...followed by this:
>
> Feb 11 23:06:36 poseidon mythbackend: 2014-02-11 23:06:36.478976 E
> TFW(/video/recordings/2021_20140212043500.mpg:75): Maximum buffer size exceeded.
> Feb 11 23:06:36 poseidon mythbackend: file will be truncated, no further writing
> will be done.
> Feb 11 23:06:36 poseidon mythbackend: This generally indicates your disk
> performance
> Feb 11 23:06:36 poseidon mythbackend: is insufficient to deal with the number of
> on-going
> Feb 11 23:06:36 poseidon mythbackend: recordings, or you have a disk failure.
>
> Sounds like the exact symptoms you're seeing - file is truncated, and shows much
> larger size on in the MythFrontend UI than what is actually on the disk.  I have
> 4 ATSC tuners recording to a single, 4-disk RAID5 array, and have recently done
> some tuning of the array and disks to pretty much eliminate the problem when
> multiple tuners are recording.
>
> Is it possible your mythbackend messages are being logged somewhere other than
> where you are looking?

  Thanks for the pointer - that is exactly the cause of the problem.

  Looking at my logs, I only see it happening that once that one time.  I 
probably should rejigger my storage to optimize it a bit better.

  But this leads to a few other related questions:

1) How bug is the bugger size that the recorder uses, and can that be increased? 
  Might not do any good, but it probably wouldn't hurt.

2) Shouldn't mythtv do a better job at informing the user of this failure? 
Having to dig in the mythbackend logs hardly seems correct.  If the tuner fails 
to tune it, the recording status will say as such

3) In the case of multiple storage directories defined (like I have), it would 
also seem like mythtv could do a better job of moving from one storage directory 
to another - even if this showed up as 2 recordings, that would seem better than 
a truncated recording.