[mythtv-users] HDHR recording truncated, maximum buffer size exceeded

Greg greg12866 at nycap.rr.com
Tue Jan 1 17:29:57 UTC 2013


On 01/01/2013 11:42 AM, Joey Morris wrote:
> Monkey Pet <monkeypet at gmail.com> wrote on Mon, Dec 31, 2012 at 02:52:15PM -0800:
>>
>> On Mon, Dec 31, 2012 at 12:11 PM, Joey Morris <rjmorris at nc.rr.com> wrote:
>>
>>> I'm running 0.25.3. Twice in the past two weeks I've gotten a
>>> truncated recording from my HDHR3. Unfortunately, I didn't check the
>>> logs the first time, but last night I did, and the backend log
>>> includes an error message saying the maximum buffer size was exceeded.
>>> I've pasted that message along with a few that came right before:
>>>
>>> Dec 30 21:04:02 conquistador mythbackend[9516]: N Expire
>>> autoexpire.cpp:640 (SendDeleteMessages) Expiring 15958 MB for 1501 at
>>> 2012-12-30T17:08:00 => "NFL Football":"Green Bay Packers at Minnesota
>>> Vikings"
>>> Dec 30 21:04:36 conquistador mythbackend[9516]: W TFWWrite
>>> ThreadedFileWriter.cpp:499 (DiskLoop)
>>> TFW(/media/storage1/recordings/1171_20121230202000.mpg:72): write(57904)
>>> cnt 997 total 57545296 -- took a long time, 31048 ms
>>> Dec 30 21:05:11 conquistador mythbackend[9516]: W TFWWrite
>>> ThreadedFileWriter.cpp:499 (DiskLoop)
>>> TFW(/media/storage1/recordings/1171_20121230202000.mpg:72): write(57716)
>>> cnt 2094 total 120834556 -- took a long time, 33638 ms
>>> Dec 30 21:05:20 conquistador mythbackend[9516]: E HDHRStreamHandler
>>> ThreadedFileWriter.cpp:216 (Write)
>>> TFW(/media/storage1/recordings/1171_20121230202000.mpg:72): Maximum buffer
>>> size exceeded.#012#011#011#011file will be truncated, no further writing
>>> will be done.#012#011#011#011This generally indicates your disk performance
>>> #012#011#011#011is insufficient to deal with the number of on-going
>>> #012#011#011#011recordings, or you have a disk failure.
>>> Dec 30 21:05:35 conquistador mythbackend[9516]: W TFWWrite
>>> ThreadedFileWriter.cpp:499 (DiskLoop)
>>> TFW(/media/storage1/recordings/1171_20121230202000.mpg:72): write(57528)
>>> cnt 2326 total 134208688 -- took a long time, 22774 ms
>>>
>>> At the time of the error, Myth was writing that single recording to
>>> disk, it was commflagging that recording, and it was possibly deleting
>>> another recording. I say "possibly" deleting, because I don't know
>>> whether that note means the deletion started immediately, and if so,
>>> how long it took to complete. It had just finished (at 21:01)
>>> recording another show, and it appears to have recorded that one
>>> successfully.
>>>
>>> A few other details:
>>>
>>> - I'm recording to a locally attached hard drive.
>>> - The drive is dedicated to MythTV recordings. (The OS and database
>>>    are on a separate drive.)
>>> - The drive is formatted as ext3.
>>> - I didn't see anything in the system logs, dmesg, or smart results that
>>>    would indicate a drive problem.
>>>
>>> This behavior is similar to what is described in these two earlier
>>> threads, although I didn't see anyone else reporting a file deletion
>>> prior to the error:
>>>
>>> http://www.gossamer-threads.com/lists/mythtv/users/522449
>>> http://www.gossamer-threads.com/lists/mythtv/users/524829
>>>
>>> The last post of that second thread mentions a patch that may help the
>>> problem: http://code.mythtv.org/trac/ticket/11061. I think my next
>>> step will be to try the patch, but I wonder if it would simply be
>>> masking bigger problems in the system, like a failing drive.
>>>
>>> Do you think this is indicative of a failing hard drive, or do you
>>> think the patch really is the appropriate solution? Would I be less
>>> likely to experience this problem if I changed the drive to ext4?
>>>
>>> Thanks for any comments.
>>
>> This is a long shot, but when I had recording truncation issues, the HDHR
>> was dropping off the network and had to continuously ping it to keep it
>> alive.  Also why are you still on mythtv 0.25 instead of the 0.26?
>>
>> http://www.mythtv.org/wiki/Silicondust_HDHomeRun_Prime#Troubleshooting
>>
>> *My recordings are being mysteriously truncated.*
>>
>>     - Try increasing the network buffers: sysctl -w net.core.rmem_max=1048576
>>     - There is a bug in certain HDHomeRun Prime tuners with the 20120405
>>     firmware which leads to it dropping off the network, leading to truncated
>>     recordings, broken LiveTV streams, and glitchy recordings. The workaround
>>     is to continuously ping the
>> HDHR<http://code.mythtv.org/trac/ticket/10414#comment:25>
>>     .
>>     - Check for packet loss, see the Troubleshooting section on the SiliconDust
>>     HDHomeRun <http://www.mythtv.org/wiki/Silicondust_HDHomeRun> page.
>>
>
> (Fixed top posting. See http://www.mythtv.org/wiki/Mailing_List_etiquette#Bottom_post.)
>
> Just to clarify, this isn't a Prime. It's a "regular" hdhomerun.
>
> I tried the low-level check for packet loss, but it didn't produce any
> results. The save command didn't produce a series of dots like the
> instructions said it would. When I killed it a couple minutes later,
> it reported 0 packets received. Watching live TV or recording
> something works fine though, so it's obviously transmitting packets.
> Are there other ways to troubleshoot hdhomerun network problems? I do
> identify the hdhomerun by device ID and not its IP in mythtv-setup. My
> hdhomerun is connected to the network via a switch.
>
> Also, I don't understand how networking problems would cause this
> error. Why would MythTV complain about exceeding the buffer size when
> writing to disk if it's having problems getting data from the tuner?
> Wouldn't that result in too little data in the buffer instead of too
> much?
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
I am sure people have made it work,but I was never successful getting 
the HDHR to work off a switch...I used mine plugged into a router and it 
never failed me...Have you tried the Silicondust forums for answers?


More information about the mythtv-users mailing list