[mythtv-commits] Ticket #11539: New capture card Hauppauge WinTV-HVR-950Q FE_GET_INFO No Such Device
MythTV
noreply at mythtv.org
Tue May 14 05:46:19 UTC 2013
#11539: New capture card Hauppauge WinTV-HVR-950Q FE_GET_INFO No Such Device
-------------------------------------+-------------------------------------
Reporter: Jim Carter <jimc@…> | Owner: danielk
Type: Bug Report - | Status: new
General | Milestone: unknown
Priority: minor | Version: 0.26
Component: MythTV - Mythtv- | Keywords: hauppauge 950q
setup | FE_GET_INFO
Severity: medium |
Ticket locked: 0 |
-------------------------------------+-------------------------------------
Versions:
* 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.
--
Ticket URL: <http://code.mythtv.org/trac/ticket/11539>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center
More information about the mythtv-commits
mailing list