[mythtv-users] HD-PVR: Encoding Errors Running 0.22
ayoung at teleport.com
Tue Dec 1 00:37:07 UTC 2009
David Engel wrote:
> On Sat, Nov 28, 2009 at 10:30:36AM -0700, Alan Young wrote:
>> David Engel wrote:
>>> I thought everyone already knew this, but just in case... Mythtv has
>>> a workaround for the problem for the problem when the hdpvr stops
>>> recording. When mythtv hasn't received data in some period of time,
>>> it assumes the hdpvr stopped and restarts the recording. If mythtv
>>> didn't do this, the recording would end at the firts gap you see, the
>>> backend would be wedged affecting later recordings and there would be
>>> a lot more unhappy hdpvr users.
>> Do you know where this timeout is at? Maybe it needs to be
>> shortened to lessen the size of the gaps?
> It's in MpegRecorder::WaitFor_HDPVR(). The timeout is currently set
> to 5 seconds. Keep mind if you make it too short, you will create
> false positives.
My cable experiment in the other thread kinda worked. With the new cable and
kernel I'm now seeing timeout messages like this in the log:
usb 1-1: mythbackend timed out on ep1in len=0/8192
Which is odd cause device 1-1 is the hub not the hdpvr itself.
That's lead me into digging into the source of the unofficial .21 fixes patch
and comparing it to what's currently in the official source.
I noticed a very interesting change in Jean Yves 49_hdpvrsupport.dpatch.
There's a change in DeviceReadBuffer::Poll(void) that increases the poll
timeout that seems to point to "Error poll giving up" message. Here's the
- int ret = poll(&polls, 1 /*number of polls*/, 10 /*msec*/);
- if (IsPauseRequested() || !IsOpen() || !run)
+ int ret = poll(&polls, 1 /*number of polls*/, 250 /*msec*/);
I'm going to try to increase timeout that first and see what happens.
More information about the mythtv-users