Opened 6 years ago

Closed 6 years ago

#12074 closed Bug Report - General (Invalid)

hvr-2250 fails to open one dvb device

Reported by: gdelx001@… Owned by:
Priority: minor Milestone: unknown
Component: MythTV - General Version: Unspecified
Severity: medium Keywords: device initialization tuning atsc dvb composite
Cc: Ticket locked: no

Description

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.

Change History (4)

comment:1 in reply to:  description ; Changed 6 years ago by Raymond Wagner

Replying to gdelx001@…:

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.

If an external application has opened and locked the tuner, MythTV will be unable to do so itself. Unless configured otherwise, MythTV opens and locks any digital tuners it wants to access as soon as it runs, and holds them locked until the application is terminated, to prevent this situation.

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.

Correct. MythTV has no way of knowing that the analog and digital input pairs are mutually exclusive. It will happily try and fail to use them unless you inform it otherwise.

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.

This is exactly the purpose of input groups. Both devices in the pair should share a common input group, so MythTV knows not to use them both at the same time.

comment:2 in reply to:  1 Changed 6 years ago by gdelx001@…

Replying to wagnerrp:

Replying to gdelx001@…:

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.

This is exactly the purpose of input groups. Both devices in the pair should share a common input group, so MythTV knows not to use them both at the same time.

If this is precisely the purpose (to be considered in initial configuration), why, when I set up the input groups, does MythTV continue to fail to _initialize_ one of the DVB adapters?

comment:3 Changed 6 years ago by Raymond Wagner

Since this appears to be a user or configuration issue, rather than a bug in MythTV, I'm going to close this. Please take this up on the mailing list, IRC channel, or forum. If it is determined there to in fact be something that needs to be fixed in MythTV, this ticket can be re-opened.

comment:4 Changed 6 years ago by Raymond Wagner

Resolution: Invalid
Status: newclosed
Note: See TracTickets for help on using tickets.