id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,mlocked 12074,hvr-2250 fails to open one dvb device,gdelx001@…,," 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. ",Bug Report - General,closed,minor,unknown,MythTV - General,Unspecified,medium,Invalid,device initialization tuning atsc dvb composite,,0