Timeout for giving up on recordings in DRB should differ depending on device

[register@…]

First observed in SVN 21253. Rolled back to SVN 20574 (detailed below) and now no longer occurring, i.e. 20574 is fine, breakage occurs sometime after 20574, but has definitely occurred by 21253.

This only happens 'every so often' - perhaps one recording in four. It only occurs on my DVB-T card (my DVB-S card has exhibited no problems).

Kernel (2.6.29-gentoo-r5) and GCC (Gentoo 4.3.2-r3 p1.6, pie-10.1.5) have remained the same through SVN revisions.

MythTV Version : 20574 MythTV Branch : trunk Library API : 0.22.20090424-2 Network Protocol : 45 QT Version : 4.5.1 Options compiled in:

linux profile using_oss using_alsa using_backend using_dvb using_firewire using_frontend using_glx_proc_addr_arb using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_libfftw3 using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_libavc_5_3 using_live using_mheg

[Janne Grunau]

please attach a -v channel,record,siparser log

make sure that the channel with Program #7450 (service_id in the channelk table) is broadcasting when the recording fails.

Make/model/drivers of the DVB-T card are also interesting

[anonymous]

lspci -v (on DVB-T card):

02:08.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)

Subsystem: Technotrend Systemtechnik GmbH Technotrend-Budget/Hauppauge? WinTV-NOVA-T DVB card Control: I/O- Mem+ BusMaster?+ SpecCycle?- MemWINV- VGASnoop- ParErr?- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr?- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32 (3750ns min, 9500ns max) Interrupt: pin A routed to IRQ 11 Region 0: Memory at e0005000 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget dvb Kernel modules: budget

will do a -v channel,record,siparser log when I get a chance to rebuild & install SVN 21253 (around 25th Aug)

[register@…]

Log file detailing error state

[register@…]

OK, I've uploaded a log file where the error occurs (@ 2009-08-24 21:19:20.551).

Let me know if you need anything else.

[register@…]

FWIW, I've been 'backtracking' from r21253 to try and identify where the bug was introduced.

So far, I've confirmed r20659 is 'bad' and am testing r20616, which seems OK, but am not holding my breath.

[Shane Shrybman]

Hi, sorry for the slow response. This is a known problem without a known cause or solution at this time. :/

I suspect that reverting change set [20617] might be a temporary workaround.

A more interesting test would be to revert back to a older kernel (2.6.28 or before) and see if the problem disappears or is at least less frequent there.

[register@…]

Just had a quick stab with 2.6.28-gentoo-r6 and r21371 and got the same error message. May be able to try a 2.6.27 flavour another day.

[Matthias "mortalmatt" Dahl <devel@…>]

I had been trying to track this down as well. Unfortunately, my system changed a bit the last few weeks which made it so much harder for me to trigger this... haven't seen the stream handler giving up on me ever since. Which is also a good thing. ;)

Could you maybe try kernel commit b2add73dbf93fd50f00564d7abc3e2b9aa9dd20c w/ 2.6.30.5 and see if that changes things for you? That's the only poll related commit and in theory it shouldn't matter but who knows. You have to get the patch from kernel.org's gitweb and patch the 2.6.30.5 yourself.

Can you reliably trigger this or does it happen like one out of ten recordings...? Which filesystem are you using? I'm asking because for me, w/ write barriers on, I could easily run into this issue (with ext4) and w/ write barriers disabled, things just worked fine. I bet this is a timing issue somewhere. I have switched over to a sw RAID5 and currently there are no write barriers supported which is very bad for data integrity but good for mythtv. Oh well.

Do you have a single partition with your mythtv recordings and mysql databases?

[register@…]

I'll try and checkout commit b2add73dbf93fd50f00564d7abc3e2b9aa9dd20c when I get a chance.

I can trigger the problem usually within a hour or two of starting recording. Currently I'm running r20616 on a variety of kernels and it's stable.

The box is running on reiserfs on a software RAID5 configuration. The whole box is running on a single 1.8TB partition. FWIW, CPU (Intel Core 2 CPU 6400 @ 2.13GHz) usage is low - usually around 10%.

[Matthias Dahl <devel@…>]

Could you please try the following patch? It's just a test, so please don't get your hopes up too early.

The changes:

• polling is done indefinitely with a nice warning ("No data seen for xx msecs") if it takes longer than expected

• the one and only mutex in poll's execution path was replaced by an atomic operation which will speed things up and avoid unnecessary/unpredictable wait states

While testing, watch out for the log message above. That's the point where the stream handler would have usually "died". Check your recording if it contains any corruptions around that time frame or if it's totally okay.

As a side note. I think the stream handler should never quit because there hasn't been any data for some time. It's always better to miss some part of a recording than the whole recording itself.

Thanks for taking the time...

[register@…]

OK, updated to r21371 and applied the patch. I saw the following in the log:

ankh@ted /var/log/mythtv $ cat mythbackend.log | grep "No data" 2009-08-31 12:47:36.844 DevRdB(/dev/dvb/adapter100/frontend0) Error: No data seen for 2505 msecs.

I watched the recording at around the time the message was logged and, yes, there does appear to be a small 'gap' in the recording, but it continues to record (& playback) after the interruption in the stream. Good!

I'll leave my system on r21371 + patch for a few more days and report back any issues.

BTW, still on Linux 2.6.28-gentoo-r6 from previous testing.

[Matthias Dahl <devel@…>]

Is your DVB-T reception generally very stable or do you happen to have short stream interruptions or corruptions from time to time? (before [20617]) With [20617] applied, MythTV is a lot more sensitive to interruptions, so before [20617] you would only have seen gaps or similar things like with the patch above but with [20617] the streamhandler quits with an error.

[panachoi@…]

I just wanted to put another data point in here. I'm horribly plagued by this. But I cannot reliably reproduce the problem. I'm pretty sure (from my testing) that it occurs for me on a single multiplex (DVB-C only); other mplexes and DVB-S record fine, but anything I attempt to record on the single affected multipex is a crapshoot. I tried 4 times yesterday, and only 1 of the 4 recordings worked, the other three usually died within 1/2 hour of starting with the usual:

2009-09-12 10:54:16.527 DVBRec(3:/dev/dvb/adapter3/frontend0) Error: Stream handler died unexpectedly.
2009-09-12 17:00:05.467 DVBRec(3:/dev/dvb/adapter3/frontend0) Error: Stream handler died unexpectedly.
2009-09-12 18:46:16.273 DVBRec(3:/dev/dvb/adapter3/frontend0) Error: Stream handler died unexpectedly.

I will try the aforementioned patch to see what happens.

[Matthias Dahl <devel@…>]

Thanks panachoi for reporting back. The patch above does _not_ actually fix the underlying problem if there is any at all. It just makes MythTV keep going in case there hasn't been any data for a period of time. You'll very likely experience corruption of that particular recording at that specific position.

I'd like give another idea a try that I had after looking over the dvb sources and some more over the DeviceReadBuffer?. It'd be great if any of you guys could try a new patch I'll post ASAP hopefully, depending on how quickly I can start working on it. (Un)fortunately I can no longer reproduce the problem on my machine, so it's hard to track it down.

One more thing: Could you please try either kernel 2.6.30.6 or 2.6.31, just to make sure if the poll related fix that went in there changes things.

Last but not least: With the patch above applied, you will see a log message like "No data seen for xx msecs." where xx is the number of msecs instead of MythTV stopping the recording. Could you please post some figures including other error messages that happened around that time frame? Thanks. (needs MythTV run w/ at least important and record log messages enabled)

[Matthias Dahl <devel@…>]

Guys, could you please try the new patch above? Turn on logging of at least important and recording related messages and watch out for any error msg which comes from the DeviceReadBuffer? (log msgs prefixed w/ DevRdB).

Be advised, the patch has only been compile tested so far, so don't put it on a production box, even though I am going to. :) In theory it should make MythTV more resilient against certain error conditions and should speed up transfer of the ts packets from the device's buffer.

Could you also please check your old logs if you saw any messages that the device buffers overflowed approx. around the time frame the stream handler died?

Thanks for testing and please report back.

[Matthias Dahl <devel@…>]

Ok... just for the faint of heart: I just got the time to make several test recordings and everything worked fine. :-)

[register@…]

Ouch. What happed to gnome42?

Anyway, OP here. I've stopped getting the "No data seen for..." messages since I upgraded to 2.6.30-gentoo-r6 (which I think is vanilla 2.6.30.6 + patches) on about 3rd Sept. Haven't noticed any recordings abending either.

Will try patch when I get a moment, but if kernel update has 'fixed' the problem, don't know how much help I'll be...

[Matthias Dahl <devel@…>]

That _could_ confirm that the fix that went in 2.6.30.6 and 2.6.31 actually fixed this bug here too.

Nevertheless, I'd like to suggest merging the patch above nevertheless. I just had feedback from Panachoi who tried it and hasn't seen any problems so far either. It'll make MythTV at least more resilient to errors, won't die until really necessary and get the data away from the dvb device asap.

I'll post an updated patch tomorrow which contains a minor fix for an issue reported by Panachoi. That patch should be clear for merging then if wanted.

[Matthias Dahl <devel@…>]

Sorry for my late posting. The v2 patch can be merged if wanted. The minor issue I talked about earlier was false alarm on my side (better be safe than sorry). I have been running MythTV w/ the patch applied for two days now, made several different recordings and I noticed no side effects. So I consider it safe and an improvement over current behavior even if 2.6.30.6 / 2.6.31.x fixed an underlying problem, MythTV shouldn't die easily.

[Matthias Dahl <devel@…>]

One more thing: Judging from my quick (!) look over the DVB tree, the patch will also improve behavior during bad reception conditions or short outtages which in theory would lead to the DeviceReadBuffer? giving up too.

[register@…]

Here are my logs going back to Aug 24th - patch applied on Aug 31st:

ankh@ted /var/log/mythtv $ cat mythbackend.log | grep DevRdB
2009-08-24 11:02:12.911 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-08-24 11:30:10.721 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-08-24 12:08:19.218 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-08-24 12:38:07.605 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-08-24 13:09:22.106 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-08-24 14:21:28.362 DevRdB(/dev/dvb/adapter200/frontend0): buffer size 9400 KB
2009-08-24 16:39:11.767 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-08-24 16:40:09.854 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-08-24 16:41:46.879 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-08-24 18:18:10.075 DevRdB(/dev/dvb/adapter200/frontend0): buffer size 9400 KB
2009-08-24 19:56:06.290 DevRdB(/dev/dvb/adapter200/frontend0): buffer size 9400 KB
2009-08-24 20:58:09.178 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-08-24 21:19:20.172 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll giving up
2009-08-24 21:19:20.204 DevRdB(/dev/dvb/adapter100/frontend0): fill_ringbuffer: error state
2009-08-24 21:58:07.432 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-08-24 22:00:01.163 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll giving up
2009-08-24 22:00:01.288 DevRdB(/dev/dvb/adapter100/frontend0): fill_ringbuffer: error state
2009-08-24 22:33:06.261 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-08-30 00:10:24.825 DevRdB(/dev/dvb/adapter200/frontend0) Error: Driver buffers overflowed
2009-08-31 12:41:11.450 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-08-31 12:47:36.844 DevRdB(/dev/dvb/adapter100/frontend0) Error: No data seen for 2505 msecs.
2009-08-31 14:21:21.740 DevRdB(/dev/dvb/adapter100/frontend0) Error: No data seen for 2503 msecs.
2009-08-31 15:01:06.603 DevRdB(/dev/dvb/adapter100/frontend0) Error: No data seen for 2510 msecs.
2009-09-05 23:40:27.289 DevRdB(/dev/dvb/adapter200/frontend0) Error: Driver buffers overflowed
2009-09-05 23:40:28.966 DevRdB(/dev/dvb/adapter200/frontend0): poll error
2009-09-08 18:20:09.250 DevRdB(/dev/dvb/adapter100/frontend0) Error: Driver buffers overflowed

Should be able to apply the patch soon and report back.

[anonymous]

Been running v2 of the patch since 16th Sept without any noticeable problems. Log since patch applied:

ted mythtv # cat mythbackend.log | grep DevRdB
2009-09-16 13:49:00.992 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-16 20:58:06.896 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-16 21:58:54.463 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4132 msecs.
2009-09-17 02:48:07.037 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-17 03:02:43.858 DevRdB(/dev/dvb/adapter100/frontend0) Error: Driver buffers overflowed
2009-09-17 03:06:35.875 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4116 msecs.
2009-09-17 08:41:52.883 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-17 09:58:04.460 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-17 10:25:08.372 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-17 10:42:49.253 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4196 msecs.
2009-09-17 13:28:07.462 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-17 15:00:08.658 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-17 19:26:06.464 DevRdB(/dev/dvb/adapter200/frontend0): buffer size 9400 KB
2009-09-17 20:58:05.382 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-17 21:58:05.064 DevRdB(/dev/dvb/adapter200/frontend0): buffer size 9400 KB
2009-09-17 23:58:06.024 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-18 07:18:06.021 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-18 08:23:09.482 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-18 08:31:18.954 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4146 msecs.
2009-09-18 08:36:19.671 DevRdB(/dev/dvb/adapter100/frontend0) Error: Driver buffers overflowed
2009-09-18 09:58:07.686 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-18 13:28:06.984 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-18 13:28:15.200 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4159 msecs.
2009-09-18 13:50:00.924 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4116 msecs.
2009-09-18 19:56:05.706 DevRdB(/dev/dvb/adapter200/frontend0): buffer size 9400 KB
2009-09-18 21:58:06.133 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-19 07:18:09.582 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-19 08:23:04.214 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-19 09:58:04.480 DevRdB(/dev/dvb/adapter200/frontend0): buffer size 9400 KB
2009-09-19 11:58:03.888 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-19 12:06:52.667 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4209 msecs.
2009-09-19 12:28:04.379 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-19 12:31:48.021 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4102 msecs.
2009-09-19 12:32:24.266 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 8246 msecs.
2009-09-19 18:23:07.371 DevRdB(/dev/dvb/adapter200/frontend0): buffer size 9400 KB
2009-09-19 20:58:06.673 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-19 21:40:08.661 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-19 22:09:17.079 DevRdB(/dev/dvb/adapter100/frontend0) Error: Driver buffers overflowed
2009-09-19 22:09:40.616 DevRdB(/dev/dvb/adapter100/frontend0) Error: Driver buffers overflowed
2009-09-19 22:09:47.734 DevRdB(/dev/dvb/adapter100/frontend0) Error: Driver buffers overflowed
2009-09-19 22:09:55.255 DevRdB(/dev/dvb/adapter100/frontend0) Error: Driver buffers overflowed
2009-09-19 22:18:04.472 DevRdB(/dev/dvb/adapter200/frontend0): buffer size 9400 KB
2009-09-19 23:05:11.107 DevRdB(/dev/dvb/adapter200/frontend0): buffer size 9400 KB
2009-09-19 23:42:56.324 DevRdB(/dev/dvb/adapter200/frontend0) Error: Driver buffers overflowed
2009-09-19 23:42:58.035 DevRdB(/dev/dvb/adapter200/frontend0) Error: Driver buffers overflowed
2009-09-19 23:43:07.328 DevRdB(/dev/dvb/adapter200/frontend0) Error: Driver buffers overflowed
2009-09-20 08:23:06.533 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-20 11:58:06.469 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-20 12:04:35.413 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4113 msecs.
2009-09-20 12:08:25.634 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4151 msecs.
2009-09-20 12:11:01.160 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4152 msecs.
2009-09-20 12:11:28.563 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4140 msecs.
2009-09-20 12:28:04.092 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-20 12:37:36.994 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4175 msecs.
2009-09-20 12:41:22.118 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4160 msecs.
2009-09-20 12:41:35.360 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4136 msecs.
2009-09-20 12:43:00.120 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4194 msecs.
2009-09-20 12:50:19.618 DevRdB(/dev/dvb/adapter100/frontend0) Error: Driver buffers overflowed
2009-09-20 15:06:06.164 DevRdB(/dev/dvb/adapter200/frontend0): buffer size 9400 KB
2009-09-20 15:52:13.736 DevRdB(/dev/dvb/adapter200/frontend0) Error: Driver buffers overflowed
2009-09-20 18:58:07.702 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-20 22:53:06.908 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-20 22:55:49.541 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4124 msecs.
2009-09-20 22:57:20.786 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4161 msecs.
2009-09-20 23:10:57.119 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4181 msecs.
2009-09-20 23:11:10.385 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4159 msecs.
2009-09-20 23:12:55.012 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4118 msecs.
2009-09-20 23:17:00.378 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4176 msecs.
2009-09-20 23:17:42.282 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4202 msecs.
2009-09-20 23:32:57.026 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4174 msecs.
2009-09-20 23:51:31.483 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4209 msecs.
2009-09-21 07:18:05.932 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-21 08:23:05.157 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-21 08:24:57.250 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4107 msecs.
2009-09-21 08:33:17.089 DevRdB(/dev/dvb/adapter100/frontend0) Error: Driver buffers overflowed
2009-09-21 08:55:26.722 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 442629 msecs.
2009-09-21 09:20:26.115 DevRdB(/dev/dvb/adapter100/frontend0) Error: Driver buffers overflowed
2009-09-21 09:58:04.118 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-21 10:15:09.619 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4146 msecs.
2009-09-21 10:25:08.577 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB
2009-09-21 10:34:27.392 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4190 msecs.
2009-09-21 10:40:02.232 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4161 msecs.
2009-09-21 10:45:21.664 DevRdB(/dev/dvb/adapter100/frontend0) Error: Poll() took too long: runtime 4172 msecs.
2009-09-21 17:58:06.492 DevRdB(/dev/dvb/adapter100/frontend0): buffer size 9400 KB

[danielk]

(In [21976]) Refs #6897. Applies a conservative workaround to DVB timeout problem.

The DVB driver bug has apparently been fixed as of Linux 2.6.31, so 2.6.28 through 2.6.30 are the only affected releases. In any case I'm leaving the ticket open because it appears we really want two different behaviours depending on the device. For DVB devices we want to wait a long time recovery, while for HD-PVR devices we want to exit poll so we can reset the device, since it will not auto-recover. In all cases we probably are dealing with real error conditions that result in bits missing from the recording so we should note this and mark the recording as damaged.

[danielk]

Fixed upstream about a year ago, we installed a workaround in MythTV 11 months ago. If someone is still affected by this the best course is just to avoid the two kernel releases with the bug.