Opened 9 years ago

Closed 8 years ago

#11539 closed Bug Report - General (Upstream Bug)

New capture card Hauppauge WinTV-HVR-950Q FE_GET_INFO No Such Device

Reported by: Jim Carter <jimc@…> Owned by: danielk
Priority: minor Milestone: unknown
Component: MythTV - Mythtv-setup Version: 0.26
Severity: medium Keywords: hauppauge 950q FE_GET_INFO
Cc: Ticket locked: no



  • Capture device: Hauppauge WinTV-HVR-950Q USB ID 2040:7200 (on USB 2.0)
  • MythTV 0.26.0
  • Kernel 3.7.10 for i586
  • Distro: OpenSuSE 12.3
  • Host Hardware: Dell Zino HD 400 with AMD "Fusion Zacate"

I run mythtv-setup and try to add this capture card, but it reports on stderr:

`(timestamp) E FE_GET_INFO ioctl failed (/dev/dvb/adapter0/frontend0)

eno: No such device (19)`

w_scan (available on SuSE Build Service) can report the device's capabilities, gets a signal lock on expected frequencies, and reports expected transport streams, suggesting that the drivers are complete and competently loaded.

So what do the two programs do differently? I'm filling up your disc attaching the complete strace output (feel free to toss it), but the key sections go like this, w_scan first:

` write(2, "Info: using DVB adapter auto det"

open("/dev/dvb/adapter0/frontend0", O_RDWR|O_NONBLOCK) = 3 ioctl(3, FE_GET_INFO, 0x8089d00) = 0 Later, does FE_GET_INFO again and prints out the results. `

mythtv-setup is a whole lot more complicated with multiple threads, but here is the analogous section:

` 3553 open("/dev/dvb/adapter0/frontend0", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 47

3553 ioctl(47, FE_GET_INFO <unfinished ...><... ioctl resumed> , 0xbfebfa04) = 0 3553 close(47) 3553 open("/dev/dvb/adapter0/frontend0", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 47 ioctl(47, FE_GET_INFO, 0xbfebfa04) = -1 ENODEV (No such device) close(47) = 0


So both programs opened the frontend O_RDWR and got the info successfully, but mythtv-setup then reopened the frontend O_RDONLY, re-snarfed the info, and it failed. It seems wacko for the driver to prevent you from reading a readonly FD. Here's a wild speculation: reading capabilities could potentially lead to firmware being loaded, which is a write operation. (In my case the firmware was loaded many command lines previously.)

May I suggest to just use the successfully read info from the O_RDWR file descriptor?

This bug report is actually a duplicate of 11312 (date about 2012-12-27) with different information, but following the "don't add to tickets" rule I've made a separate ticket for it.

Attachments (4)

setup.version (848 bytes) - added by Jim Carter <jimc@…> 9 years ago.
Output of mythtv-setup --version
w_scan.str (13.5 KB) - added by Jim Carter <jimc@…> 9 years ago.
strace output for w_scan -fa -A1 -c US
mythtv-setup.str.gz (109.5 KB) - added by Jim Carter <jimc@…> 9 years ago.
strace output for mythtv-setup (failing)
aurora.modules (5.7 KB) - added by Jim Carter <jimc@…> 9 years ago.
/proc/modules on the affected host

Download all attachments as: .zip

Change History (8)

Changed 9 years ago by Jim Carter <jimc@…>

Attachment: setup.version added

Output of mythtv-setup --version

Changed 9 years ago by Jim Carter <jimc@…>

Attachment: w_scan.str added

strace output for w_scan -fa -A1 -c US

Changed 9 years ago by Jim Carter <jimc@…>

Attachment: mythtv-setup.str.gz added

strace output for mythtv-setup (failing)

comment:1 Changed 9 years ago by dekarl@…

This is a duplicate of #10830, see

Basically you are seeing a race condition in the linux dvb frontend driver. A fix has been developed, but its state on the patch tracker still says "new" see

Maybe there's some newer information to be had at the media-info list, see

Changed 9 years ago by Jim Carter <jimc@…>

Attachment: aurora.modules added

/proc/modules on the affected host

comment:2 Changed 9 years ago by J.Pilk@…

This issue has been bugging MythTV users for at least 9 months. Ticket #11058, not 11085 as I reported later. The patch has been scaring the linuxtv devs for 5 months; they feel it's a bug in individual drivers. But I suspect that most drivers are 'write and forget' and will not be fixed.

It's clear that other apps do work - eg femon, wscan. If the fix suggested above could be shown to work and not break other things, wouldn't it be worth modifying the 'not our problem' stance?

comment:3 Changed 8 years ago by Gary Buhrmaster <gary.buhrmaster@…>

This should probably be closed as a dup of #10830 and/or closed as an upstream bug (fixed in kernel 3.9, kernel commit 6ae23224557d797439d02f6ce5d10a82ab544b21

comment:4 Changed 8 years ago by stuartm

Resolution: Upstream Bug
Status: newclosed

Upstream bug in the kernel.

Note: See TracTickets for help on using tickets.