[mythtv-users] truncated recording

George Mari george_mythusers at mari1938.org
Tue Feb 18 14:48:39 UTC 2014


On 2/18/14, 12:45 AM, Mark Wedel wrote:
> 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.
I can't find the reference now, but if memory serves me, the buffer is 
hard-coded to 128MB.

I also believe the MythTV wiki has a section on storage groups, and some 
of the parameters available for balancing use across multiple devices.

Also, see http://www.mythtv.org/wiki/Optimizing_Performance  for some 
more relevant information on tuning disk performance - not everything 
there may apply to your specific situation.



More information about the mythtv-users mailing list