[mythtv-users] truncated recording

Tue Feb 18 07:47:33 UTC 2014

REMOVE ME FROM YOUR MAIL LIST. MYTHTV.ORG HAS REPEATEDLY
REFUSED TO REMOVE ME FROM THEIR LIST. USERS BEWARE !!!

>________________________________
>
>

>________________________________
> From: Mark Wedel <mwedel at sonic.net>
>To: Discussion about MythTV <mythtv-users at mythtv.org> 
>Sent: Tuesday, February 18, 2014 12:45 AM
>Subject: Re: [mythtv-users] truncated recording
>  
>
>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.
>
>
>
>_______________________________________________
>mythtv-users mailing list
>mythtv-users at mythtv.org
>http://www.mythtv.org/mailman/listinfo/mythtv-users
>http://wiki.mythtv.org/Mailing_List_etiquette
>MythTV Forums: https://forum.mythtv.org
>
>
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140217/7a6a19a1/attachment.html>