[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