RFH: Do you get 0-byte recordings? (Even infrequently) Please post info about it here

[tgm4883]

There have been a number of people saying they are getting 0-byte recordings. Fortunately the issue appears uncommon, and happens infrequently on user systems. Unfortunately, since it is so infrequent it is difficult to gather information to resolve the issue. This thread is an attempt to try and gather as much information as we can in the hopes that if MythTV can provide a fix for it they will.

The issue appears to happen across all Distros and MythTV versions. Post in this thread if you see this issue regardless of what Distro and/or MythTV version you are using.

I myself have only seen it personally on an HD-PVR, but others have reported it on DVB cards of all kinds.

If this happens to you, please post here with the following information:

Distro and release (eg. Ubuntu 10.10, Fedora 13):
Full version of the MythTV Backend package (eg. dpkg -l mythtv-backend*):
Where you get your mythtv packages from (standard repos, avenard repos, mythbuntu repos, compile from source, etc):
Tuners you see the issue on:
Other tuners on your system:
Firmware version version (eg. 'dmesg | grep hdpvr'):
Kernel Version (uname -a):
Snippet of dmesg around the time the issue is happening:
Any other info you think is relevant:

[tgm4883]

Distro and release (eg. Ubuntu 10.10, Fedora 13):
Mythbuntu 10.04

Full version of all MythTV packages (eg. dpkg -l mythtv-backend):
ii mythtv-backend 2:0.24.0+fixes.20110213.3d55e51-0ubu A personal video recorder application (server)
ii mythtv-backend-master 2:0.24.0+fixes.20110213.3d55e51-0ubu Metapackage to setup and configure a "Master Backend" profile of MythTV.

Where you get your mythtv packages from (standard repos, avenard repos, mythbuntu repos, compile from source, etc):
mythtv-updates repository (mythbuntu-repos)

Tuners you see the issue on:
HD-PVR

Other tuners on your system:
pcHDTV 5500

Firmware version version (eg. 'dmesg | grep hdpvr'):
[ 7.955363] hdpvr 1-3:1.0: untested firmware version 0x15, the driver might not work
[ 8.283460] hdpvr 1-3:1.0: device now attached to /dev/video0
[ 8.283494] usbcore: registered new interface driver hdpvr

Kernel Version (uname -a):
Linux ares 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC 2011 x86_64 GNU/Linux

Snippet of dmesg around the time the issue is happening:
N/A, issue is not happening at this moment.

Any other info you think is relevant:
In my case, the blue "halo" on the HD-PVR remains on and I get a 0-byte recording. The blue halo remains on and 0-byte recordings happen for all following recordings on that tuner until I power cycle the HD-PVR and restart the backend service.

[ck102]

Distro and release (eg. Ubuntu 10.10, Fedora 13):
Ubuntu 10.10

Full version of the MythTV Backend package (eg. dpkg -l mythtv-backend*):
ii mythtv-backend 2:0.24.0+fixes A personal video recorder application (serve
ii mythtv-backend 2:0.24.0+fixes Metapackage to setup and configure a "Master

Where you get your mythtv packages from (standard repos, avenard repos, mythbuntu repos, compile from source, etc):

mythtv-updates repository (mythbuntu-repos)

Tuners you see the issue on:
HD-PVR

Other tuners on your system:
PVR-150

Firmware version version (eg. 'dmesg | grep hdpvr'):
[ 6.364704] hdpvr 1-4:1.0: untested firmware version 0x15, the driver might not work
[ 6.683368] hdpvr 1-4:1.0: device now attached to video0
[ 6.683481] usbcore: registered new interface driver hdpvr
[ 48.516849] hdpvr 1-4:1.0: device video0 disconnected
[ 54.637145] hdpvr 1-4:1.0: untested firmware version 0x15, the driver might not work
[ 54.950956] hdpvr 1-4:1.0: device now attached to video0

Kernel Version (uname -a):
Linux mytv 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44 UTC 2011 x86_64 GNU/Linux

Snippet of dmesg around the time the issue is happening:
Not available - issue is not currently happening.

Any other info you think is relevant:
When my HD-PVR becomes unusable, it corrupts the first recording about 10 minutes in and the blue halo remains off. It then gives me 0 byte recordings until the HDPVR is power cycled. I do not have to restart the backend. I had the problem on 10.04 as well. When I was using 10.04, I tried the installing the V4L/DVB from source. I wanted to test the changes that Alan Young had made (hoping it would fix the issue) This resulted in the blue halo remaining on when it corrupted. I power cycle the HD-PVR once a week to prevent loosing recordings.

[melevittfl]

Distro and release (eg. Ubuntu 10.10, Fedora 13):
Mythbuntu 10.04


Full version of the MythTV Backend package (eg. dpkg -l mythtv-backend*):
ii mythtv-backend 2:0.24.0+fixes.20110215.72b7 A personal video recorder application (server)
ii mythtv-backend-master 2:0.24.0+fixes.20110215.72b7 Metapackage to setup and configure a "Master Backend" profile of MythTV.


Where you get your mythtv packages from (standard repos, avenard repos, mythbuntu repos, compile from source, etc):
Mythbuntu repos

Tuners you see the issue on:
myth@mythtv:~$ dmesg | grep dvb
[ 5.238720] dvb-usb: found a 'Hauppauge Nova-T Stick' in cold state, will try to load a firmware
[ 5.238725] usb 1-4: firmware: requesting dvb-usb-dib0700-1.20.fw
[ 6.538725] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw'
[ 7.248025] dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state.
[ 7.248093] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 7.308750] cx88/2: cx2388x dvb driver version 0.0.7 loaded
[ 7.308753] cx88/2: registering cx8802 driver, type: dvb access: shared
[ 7.678871] dvb-usb: Hauppauge Nova-T Stick successfully initialized and connected.
[ 7.679029] usbcore: registered new interface driver dvb_usb_dib0700


Other tuners on your system:

Firmware version version (eg. 'dmesg | grep hdpvr'):
dvb-usb-dib0700-1.20.fw'

Kernel Version (uname -a):
Linux mythtv 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 21:21:01 UTC 2011 i686 GNU/Linux

Snippet of dmesg around the time the issue is happening:
Don't have anything in dmesg logs from when it happens


Any other info you think is relevant:
I changed the tuning timeout in mythtv-setup a few days ago. It hasn't happened since, although it only ever happened every few months or so.

It has only happened since upgrading to MythTv .24 via the Mythbuntu autobuilds.

[rakmount]

Distro and release (eg. Ubuntu 10.10, Fedora 13):
Mythbuntu 10.10

Full version of the MythTV Backend package (eg. dpkg -l mythtv-backend*):
ii mythtv-backend 2:0.24.0+fixes.20110206.1a69c92 A personal video recorder application (server)
ii mythtv-backend-master 2:0.24.0+fixes.20110206.1a69c92 Metapackage to setup and configure a "Master Backend" profile of MythTV.

Where you get your mythtv packages from (standard repos, avenard repos, mythbuntu repos, compile from source, etc):
mythtv-updates repository (mythbuntu-repos)

Tuners you see the issue on:
HD-PVR
(using SPDIF input)

Other tuners on your system:
none

Firmware version version (eg. 'dmesg | grep hdpvr'):
[ 3.130840] hdpvr 1-6:1.0: untested firmware version 0x15, the driver might not work
[ 3.466100] hdpvr 1-6:1.0: device now attached to video0
[ 3.466171] usbcore: registered new interface driver hdpvr

Kernel Version (uname -a):
Linux McMyth 2.6.35-25-generic-pae #44-Ubuntu SMP Fri Jan 21 19:01:46 UTC 2011 i686 GNU/Linux

Snippet of dmesg around the time the issue is happening:
from syslog dated last occurence -
Feb 10 20:59:51 McMyth lircd-0.8.7-pre3[1039]: accepted new client on /var/run/lirc/lircd
Feb 10 20:59:51 McMyth lircd-0.8.7-pre3[1039]: removed client
Feb 10 20:59:52 McMyth lircd-0.8.7-pre3[1039]: accepted new client on /var/run/lirc/lircd
Feb 10 20:59:52 McMyth lircd-0.8.7-pre3[1039]: removed client
Feb 10 20:59:52 McMyth lircd-0.8.7-pre3[1039]: accepted new client on /var/run/lirc/lircd
Feb 10 20:59:52 McMyth lircd-0.8.7-pre3[1039]: removed client
Feb 10 21:01:14 McMyth lircd-0.8.7-pre3[1751]: MCU top is now: 50953 (a change of: 30)
Feb 10 21:01:14 McMyth lircd-0.8.7-pre3[1751]: USB received: 63, expectingBytes: 60. Hex data (headers: 134 60 0):#011
Feb 10 21:01:26 McMyth lircd-0.8.7-pre3[1751]: MCU top is now: 51247 (a change of: 5
Feb 10 21:01:26 McMyth lircd-0.8.7-pre3[1751]: USB received: 63, expectingBytes: 61. Hex data (headers: 140 61 0):#011
Feb 10 21:01:28 McMyth lircd-0.8.7-pre3[1751]: MCU top is now: 53297 (a change of: 5
Feb 10 21:01:28 McMyth lircd-0.8.7-pre3[1751]: USB received: 63, expectingBytes: 61. Hex data (headers: 184 61 0):#011

saw problem at this point and stopped recording

Feb 10 21:01:41 McMyth lircd-0.8.7-pre3[1039]: accepted new client on /var/run/lirc/lircd
Feb 10 21:01:49 McMyth lircd-0.8.7-pre3[1751]: MCU top is now: 54613 (a change of: 42)
Feb 10 21:01:49 McMyth lircd-0.8.7-pre3[1751]: USB received: 63, expectingBytes: 60. Hex data (headers: 213 60 0):#011

Snippet of MythWelcome log around the time the issue is happening:
2011-02-10 20:58:51.113 MythWelcome received a SCHEDULE_CHANGE event
2011-02-10 20:59:52.431 MythWelcome received a recording list change event
2011-02-10 20:59:52.431 MythWelcome received a recording list change event
2011-02-10 20:59:52.431 [deferred to pending handler]
2011-02-10 20:59:52.431 MythWelcome received a SCHEDULE_CHANGE event
saw problem at this point and stopped recording
2011-02-10 21:01:39.116 Locking input devices
2011-02-10 21:01:40.011 mythfrontend version: fixes/0.24 [v0.24-151-g1a69c92]

Any other info you think is relevant:
This has happened on more than one occasion, always when recording Grays Anatomy or Private Practice on a HD channel. Recording same from non-HD works. Recording other programs on same HD channel works.

I believe it may be sound related – listings (Schedules Direct) show these 2 programs in particular as stereo. Actual satellite provided listing shows them as 5.1 Dolby (I don't have precise details available at the moment) while all other successfully recorded shows from same station list merely as stereo.

After the problem occurs and another show records (hit or miss), it will have no sound. Only fix is a reboot of myth box and a power-cycle of HD-PVR.

[mookie60]

Distro and release (eg. Ubuntu 10.10, Fedora 13):
mythbuntu 9.04

Full version of the MythTV Backend package (eg. dpkg -l mythtv-backend*):

mythtv-backend 0.21.0+fixes21768
mythtv-backend-mas 0.21.0+fixes21768

Where you get your mythtv packages from (standard repos, avenard repos, mythbuntu repos, compile from source, etc):
mythbuntu repos (i think)

Tuners you see the issue on:
hauppauge 1600, pchdtv 5500

Other tuners on your system:
see above

Firmware version version (eg. 'dmesg | grep hdpvr'):
sorry, don't know what to replace hdpvr with

Kernel Version (uname -a):
what ever was the last issued for 9.04

Snippet of dmesg around the time the issue is happening:
sorry, no longer have the issue, so can't provide the info

Any other info you think is relevant:
It's been several months since this problem occurred. When it was happening, it varied from once per week, to 2-3 times per night (on either tuner).

Both my digital tuners take a long time to lock in a channel, so I thought it might be related. So I extended the signal timeout, it's currently at 5500. This seemed to improve things but I think I maxed out the adjustment.

***After setting "quick tune" (for both tuners) to "Always", the problem has never reoccurred.***

I wish I could provide more complete info, but as it's been at least 4-5 months since the problem occurred, I just don't remember the issues fully.

[ian dobson]

Hi,

I sometimes see 0 byte recordings. When I see one every recording after it is 0 byte until I reboot the box.

More info here http://ubuntuforums.org/showthread.php?t=1676491

Kernel
Linux alpha2 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44 UTC 2011 x86_64 GNU/Linux

2 DVB-C tuner cards

07:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
        Subsystem: KNC One Device 0022
        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 18
        Region 0: Memory at fb101000 (32-bit, non-prefetchable) [size=512]
        Kernel driver in use: budget_av
        Kernel modules: budget-av

07:01.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
        Subsystem: KNC One Device 002c
        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 19
        Region 0: Memory at fb100000 (32-bit, non-prefetchable) [size=512]
        Kernel driver in use: budget_av
        Kernel modules: budget-av

MythTV version

ii  libmyth-0.23-0                             0.23.1+fixes26732-0ubuntu0+mythbuntu2             Common library code for MythTV and add-on modules (runtime)
ii  libmythtv-perl                             0.23.1+fixes26732-0ubuntu0+mythbuntu2             A PERL library to access some MythTV features
ii  mythbuntu-repos                            8.5-0ubuntu0+mythbuntu~auto20101013003830         Mythbuntu repos installer
ii  mythtv-backend                             0.23.1+fixes26732-0ubuntu0+mythbuntu2             A personal video recorder application (server)
ii  mythtv-common                              0.23.1+fixes26732-0ubuntu0+mythbuntu2             A personal video recorder application (common data)
ii  mythtv-database                            0.23.1+fixes26732-0ubuntu0+mythbuntu2             A personal video recorder application (database)
ii  mythtv-transcode-utils                     0.23.1+fixes26732-0ubuntu0+mythbuntu2             Utilities used for transcoding MythTV tasks
ii  mythweb                                    0.23.1+fixes26732-0ubuntu0+mythbuntu2             Web interface add-on module for MythTV

syslog messages when the tuners die

Feb 22 01:19:25 alpha2 kernel: [116475.798614] irq 18: nobody cared (try booting with the "irqpoll" option)
Feb 22 01:19:25 alpha2 kernel: [116475.798626] Pid: 30780, comm: FahCore_a3.exe Tainted: P            2.6.35-25-generic #44-Ubuntu
Feb 22 01:19:25 alpha2 kernel: [116475.798628] Call Trace:
Feb 22 01:19:25 alpha2 kernel: [116475.798630]  <IRQ>  [<ffffffff810cbc1b>] __report_bad_irq+0x2b/0xa0
Feb 22 01:19:25 alpha2 kernel: [116475.798638]  [<ffffffff810cbe1c>] note_interrupt+0x18c/0x1d0
Feb 22 01:19:25 alpha2 kernel: [116475.798642]  [<ffffffff8102cd89>] ? ack_apic_level+0x79/0x1b0
Feb 22 01:19:25 alpha2 kernel: [116475.798645]  [<ffffffff810cc61d>] handle_fasteoi_irq+0xdd/0x110
Feb 22 01:19:25 alpha2 kernel: [116475.798648]  [<ffffffff8100cb12>] handle_irq+0x22/0x30
Feb 22 01:19:25 alpha2 kernel: [116475.798651]  [<ffffffff815921ec>] do_IRQ+0x6c/0xf0
Feb 22 01:19:25 alpha2 kernel: [116475.798655]  [<ffffffff8158add3>] ret_from_intr+0x0/0x11
Feb 22 01:19:25 alpha2 kernel: [116475.798656]  <EOI>
Feb 22 01:19:25 alpha2 kernel: [116475.798658] handlers:
Feb 22 01:19:25 alpha2 kernel: [116475.798662] [<ffffffffa0a96380>] (interrupt_hw+0x0/0x2b0 [saa7146])
Feb 22 01:19:25 alpha2 kernel: [116475.798681] [<ffffffffa005d890>] (sil24_interrupt+0x0/0x1ac [sata_sil24])
Feb 22 01:19:25 alpha2 kernel: [116475.798695] Disabling IRQ #18
Feb 22 01:19:26 alpha2 kernel: [116476.085905] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
Feb 22 01:19:26 alpha2 kernel: [116476.128119] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
Feb 22 01:19:26 alpha2 kernel: [116476.168091] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
Feb 22 01:19:26 alpha2 kernel: [116476.218061] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for end of xfer
Feb 22 01:19:26 alpha2 kernel: [116476.238064] DVB: TDA10023(0): tda10023_readreg: readreg error (reg == 0x11, ret == -5)

Running on a Asus p8p67 with a 2600CPU/16Gb ram and 8Tb RAID5 array.

Note the system was running on a quad core2 for almost 2years with out any major problems. The nobody cared errors started after upgrading the motherboard. The error can take upto a week for it to appear. I'm now testing with the irqpoll kernel parameter......

Regards
Ian Dobson

[JRoque250]

This issue has been driving me nuts.

Distro and release (eg. Ubuntu 10.10, Fedora 13):
Ubuntu 10.04

Full version of the MythTV Backend package (eg. dpkg -l mythtv-backend*):
2:0.24.0+fixes.2011

Where you get your mythtv packages from (standard repos, avenard repos,
mythbuntu repos, compile from source, etc):
ppa mythbuntu 0.24

Tuners you see the issue on:
HDHR

Other tuners on your system:
Comcast DTA
Comcast STB HD
WinTV PVR-150 (One analog tuning, one tunes to DTA output on ch 3)Firmware version version (eg. 'dmesg | grep hdpvr'):
HDHR firmware: 20100828

Kernel Version (uname -a):
2.6.32-25

Snippet of dmesg around the time the issue is happening:
TBD...

Any other info you think is relevant:
It started, perhaps only coincidentally, after the 0.24 upgrade. I've run the server for >2 years without a problem. It seems to only happen on one channel (local Fox HD) and only when scheduling a recording. Live TV, on the same tuner and channel, works fine. In fact, I've watched the scheduled recording and when it remains at 0 byte after a couple of seconds, I launch a client, tune to the second HDRH tuner and hit record - and that works.

I changed tuning on that channel to the exact frequency detected by HDHomeRun Config during scanning but that didn't help. I run Mythtv on the base OS (ubuntu) that hosts several VirtualBox guests so rebooting is not as easy for me.JR

[ianc]

It's OK for me at the moment, but I've thrown away a lot of functionality whilst trying to get it that way.

Distro and release (eg. Ubuntu 10.10, Fedora 13):
Ubuntu 10.04

Full version of all MythTV packages (eg. dpkg -l mythtv-backend):
mythtv-backend 0.23.0+fixes25423-0ubuntu0+mythbuntu2

Where you get your mythtv packages from (standard repos, avenard repos, mythbuntu repos, compile from source, etc):
mythtv-updates repository (mythbuntu-repos)

Tuners you see the issue on:
Nova-T 500 PCI

Other tuners on your system:
None now: previously also had a Freecom DVB-T USB but I removed this as part of my attempts to get a stable system

Firmware version version (eg. 'dmesg | grep hdpvr'):
$ dmesg | grep dvb
[ 109.256752] dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try to load a firmware
[ 109.256762] usb 2-1: firmware: requesting dvb-usb-dib0700-1.20.fw
[ 109.436870] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw'
[ 110.342864] dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state.
[ 110.342978] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 111.899249] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[ 112.473029] dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected.
[ 112.473220] usbcore: registered new interface driver dvb_usb_dib0700

Kernel Version (uname -a):
Linux server 2.6.32-29-generic #58-Ubuntu SMP Fri Feb 11 19:00:09 UTC 2011 i686 GNU/Linux

Snippet of dmesg around the time the issue is happening:
N/A, issue is not happening at this moment (fingers firmly crossed...).

Any other info you think is relevant:
Had this issue a lot (almost daily) at one time. Since then I have removed the USB tuner I was also using, applied all the “usual” tweaks for this card (LNA on, disable RC polling, usbcore autosuspend, quick tuning always), stopped active EIT scanning, stopped transcoding, stopped commflagging, extended timeouts, ...etc.

The two things I did that seemed to make the most difference were to disable Active EIT scanning & to set Quick Tuning to “Always”.

I still have a few issues in the log files, but I'm not convinced that these are Mythtv's fault and anyway they're not currently having any noticable detrimental effect.

So: my system has now been stable for several weeks, but it'd be nice to be able to turn some things back on.

[jusmop]

Distro and release (eg. Ubuntu 10.10, Fedora 13):
Ubuntu 10.10 Desktop AMD64

Full version of the MythTV Backend package (eg. dpkg -l mythtv-backend*):
2:0.24.0+fixes.20110302.0d3d

Where you get your mythtv packages from (standard repos, avenard repos, mythbuntu repos, compile from source, etc):
Mythbuntu.

Tuners you see the issue on:
DViCO FusionHDTV DVB-T Lite
DViCO FusionHDTV DVB-T Plus

Other tuners on your system:
Just the 2 above.

Firmware version version (eg. 'dmesg | grep hdpvr'):
Don't really understand all the dmesg guff, so here's the lines that I think are relevant to the setup of the DVB cards:

[ 11.202549] cx88/0: cx2388x v4l2 driver version 0.0.8 loaded
[ 11.203401] ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
[ 11.203407] alloc irq_desc for 17 on node 0
[ 11.203409] alloc kstat_irqs on node 0
[ 11.203422] cx8800 0000:01:09.0: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17
[ 11.204895] cx88[0]: subsystem: 18ac:db10, board: DViCO FusionHDTV DVB-T Plus [card=21,autodetected], frontend(s): 1
[ 11.204898] cx88[0]: TV tuner type 4, Radio tuner type -1
[ 11.311478] bttv: driver version 0.9.18 loaded
[ 11.311482] bttv: using 8 buffers with 2080k (520 pages) each for capture
[ 11.354306] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.8 loaded
[ 11.402294] cx88[0]/0: found at 0000:01:09.0, rev: 5, irq: 17, latency: 32, mmio: 0xfa000000
[ 11.402401] cx88[0]/0: registered device video1 [v4l2]
[ 11.402436] cx88[0]/0: registered device vbi0
[ 11.402715] bttv: Bt8xx card found (0).
[ 11.403077] bttv 0000:01:08.0: PCI INT A -> Link[APC1] -> GSI 16 (level, low) -> IRQ 16
[ 11.403086] bttv0: Bt878 (rev 17) at 0000:01:08.0, irq: 16, latency: 32, mmio: 0xfdeff000
[ 11.403134] bttv0: detected: DViCO FusionHDTV DVB-T Lite [card=128], PCI subsystem ID is 18ac:db10
[ 11.403137] bttv0: using: DViCO FusionHDTV DVB-T Lite [card=128,autodetected]
[ 11.403169] bttv0: gpio: en=00000000, out=00000000 in=00ffffff [init]
[ 11.403630] bttv0: tuner absent
[ 11.403887] bttv0: add subdevice "dvb0"
[ 11.411412] cx88[0]/2: cx2388x 8802 Driver Manager
[ 11.411432] cx88-mpeg driver manager 0000:01:09.2: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17
[ 11.411440] cx88[0]/2: found at 0000:01:09.2, rev: 5, irq: 17, latency: 32, mmio: 0xf9000000
[ 11.558456] bt878: AUDIO driver version 0.0.0 loaded
[ 11.558601] bt878: Bt878 AUDIO function found (0).
[ 11.558617] bt878 0000:01:08.1: PCI INT A -> Link[APC1] -> GSI 16 (level, low) -> IRQ 16
[ 11.558620] bt878_probe: card id=[0xdb1018ac],[ DViCO FusionHDTV DVB-T Lite ] has DVB functions.
[ 11.558627] bt878(0): Bt878 (rev 17) at 01:08.1, irq: 16, latency: 32, memory: 0xfdefe000
[ 11.800473] DVB: registering new adapter (bttv0)
[ 12.110563] DVB: registering adapter 0 frontend 0 (Zarlink MT352 DVB-T)...
[ 13.188142] cx88/2: cx2388x dvb driver version 0.0.8 loaded
[ 13.188146] cx88/2: registering cx8802 driver, type: dvb access: shared
[ 13.188149] cx88[0]/2: subsystem: 18ac:db10, board: DViCO FusionHDTV DVB-T Plus [card=21]
[ 13.188152] cx88[0]/2: cx2388x based DVB/ATSC card
[ 13.188154] cx8802_alloc_frontends() allocating 1 frontend(s)
[ 13.810339] DVB: registering new adapter (cx88[0])
[ 13.810345] DVB: registering adapter 1 frontend 0 (Zarlink ZL10353 DVB-T)...

Kernel Version (uname -a):
Linux pooper 2.6.35-23-generic #41-Ubuntu SMP Wed Nov 24 11:55:36 UTC 2010 x86_64 GNU/Linux

Snippet of dmesg around the time the issue is happening:
dmesg does not have any output after booting - at least for me...

Any other info you think is relevant:
I've been running MythTV for years (always fixes and always upgrading both MythTV and Ubuntu, whenever a new release of either comes out) and have not noticed this problem before. Two weeks ago it happened 11 times in 4 days. Some recordings during that time were fine. After upgrading 0.24-fixes and other Ubuntu updates 3 days ago (like I always do whenever the system tells me updates are available), and doing the required reboot (the update included a new kernel) I have not seen this issue since.

Also, a friend recently updated MythTV from 0.23-fixes to 0.24-fixes 2 weeks ago but did *not* update his OS (Ubuntu 10.04) and immediately saw the issue (again, last week).


Cheers,
Justin.