[mythtv] Debugging DeviceReadBuffer.cpp

[Thomas Börkel]

HI!

On 14.06.2013 18:29, Michael T. Dean wrote:

> But reading and writing are both tightly coupled--if we can't write to
> the disk, we could fill up the buffer that's reading from the device or
> something...  I don't know what's going on in this (these?) particular
> case(s), but it's not as simple as "MythTV shouldn't give up"--it seems
> there's a /serious/ failure somewhere, and since MythTV relies on
> hardware, if the hardware isn't doing what we need it to do to have a
> successful recording, there's not a lot MythTV can do about it.

When MythTV can't write fast enough to the disk, you get a different
message in the log:

TFW(/work2/video/recordings/63205_20130608212000.mpg:105): write(37976)
cnt 26 total 1564536 -- took a long time, 1107 ms

My case (and I guess also Malcolm's) is that there is something wrong
with reading the data from the dvb device.

In this case, Myth 0.26 stays in the poll loop until the scheduled end
of the recording and then writes the "Poll took an unusually long time"
message.

In the meantime, I modified my patch, so that it exists the loop, but
then I get:

DevRdB(/dev/dvb/adapter3/frontend0): End-Of-File? fd(98)
DVBSH(/dev/dvb/adapter3/frontend0): Device EOF detected
DVBRec(4:/dev/dvb/adapter3/frontend0): Stream handler died unexpectedly.

The (small) advantage is, that I see in MythWeb the real length of the
recording. With the original code, I see the scheduled length.

But, my point is, that MythTV should try a little harder to rescue the
recording. When there is something bad going on with the dvb device (I
think in my case it is a reception issue every now and then probably a
lost of the lock), it should try to re-lock and continue, not just stay
in the poll loop.

Otherwise a one-time show is lost forever.

Regards,
Thomas