[mythtv-commits] Ticket #12074: hvr-2250 fails to open one dvb device

[MythTV]

#12074: hvr-2250 fails to open one dvb device
-------------------------------------+-------------------------------------
     Reporter:  gdelx001@…           |      Owner:
         Type:  Bug Report -         |     Status:  new
  General                            |  Milestone:  unknown
     Priority:  minor                |    Version:  Unspecified
    Component:  MythTV - General     |   Keywords:  device initialization
     Severity:  medium               |  tuning atsc dvb composite
Ticket locked:  0                    |
-------------------------------------+-------------------------------------
 Using rpmfusion.org's "mythtv-backend-0.27-4.fc20.x86_64" package on a
 Fedora 20 box...

 I have 2x Hauppauge WinTV HVR-2250 cards, trying them out to use ATSC.

 I have also assigned those cards in mythtv for composite input (as MPEG
 card type).  I suspect this detail is key.

 Of the 4 DVB adapters (2 per card) the machine provides to me in /dev/dvb
 and that I have configured into MythTV backend, 1 is consistently missing
 in MythTV.  In logs got error messages:


 {{{
 E [/] CoreContext recorders/dvbchannel.cpp:245 (Open) -
 DVBChan[20](/dev/dvb/adapter0/frontend0): Failed to get frontend
 information.
                         eno: Interrupted system call (4)
 E [/] CoreContext recorders/channelbase.cpp:1232 (CreateChannel) -
 ChannelBase: CreateChannel() Error: Failed to open device
 /dev/dvb/adapter0/frontend0
 E [/] CoreContext main_helpers.cpp:199 (setupTVs) - Problem with capture
 cardsCard 20failed init
 }}}




 I ran azap against the missing device from mythbackend using tunable OTA
 channels, and achieved channel lock with good signal and snr.  femon
 against the device confirmed it was tuned and locked.

 I read somewhere that one needed to run femon against DVB adapters to keep
 the devices open and active to protect against some sort of race between
 mythbackend and DVB driver shifting the device to standby. Tried that, but
 it didn't change the outcome: other than which specific adapter that
 suffers the "interrupted system call" may change.


 Incidentally, the DVB adapters that do appear properly in mythbackend work
 (produce video+audio) as expected.

 In case it helps in determining order, I include the potentially relevant
 parts of the capturecard "mythconverg db" table:


 {{{
 capturecard
 +--------+-----------------------------+----------+--------------+
 | cardid | videodevice                 | cardtype | defaultinput |
 +--------+-----------------------------+----------+--------------+
 |     15 | /dev/video0                 | MPEG     | composite    |
 |     16 | /dev/video2                 | MPEG     | composite    |
 |     17 | /dev/video1                 | MPEG     | composite    |
 |     18 | /dev/video3                 | MPEG     | composite    |
 |     19 | /dev/dvb/adapter0/frontend0 | DVB      | DVBInput     |
 |     20 | /dev/dvb/adapter2/frontend0 | DVB      | DVBInput     |
 |     21 | /dev/dvb/adapter1/frontend0 | DVB      | DVBInput     |
 |     22 | /dev/dvb/adapter3/frontend0 | DVB      | DVBInput     |
 +--------+-----------------------------+----------+--------------+

 }}}


 Perhaps there is a problem that myth isn't informed that pairs of these
 capturecard entries are related, and therefore doesn't resolve some
 conflicting configuration it performs on each individual device. Possibly
 initialization results in some parallel race where the composite input is
 touched by myth at the same time the corresponding
 dvb input is touched.

 I made some small confirmation of this idea by temporarily having mythtv
 ignore the composite encoding devices (renaming their dev path to
 something that doesn't exist and restarting myth).  The dvb devices all
 appeared properly and function.  Restoring the composite devices to myth
 restores the problem.

 I created inputgroups for the proper pairs, but this hasn't helped.  This
 doesn't surprise me, because I suspect inputgroups was not intended to be
 considered in initial configuration anyway, and probably shouldn't be.

--
Ticket URL: <https://code.mythtv.org/trac/ticket/12074>
MythTV <http://www.mythtv.org>
MythTV Media Center