[linux-dvb] Unable to query frontend status with dvbscan

Stefano Sabatini stefano.sabatini-lala at poste.it
Sat Oct 18 13:26:24 CEST 2008


On date Thursday 2008-10-16 22:54:54 +0200, Stefano Sabatini wrote:
> On date Thursday 2008-10-16 07:19:18 -0600, Mark Paulus wrote:
> > Stefano Sabatini wrote:
> >> On date Tuesday 2008-10-14 23:24:02 +0200, Stefano Sabatini wrote:
> >>> Hi all,
> >>>
> >>> can you say what's the meaning of such a message?
> >>>
> >>> I'm using it with:
> >>> dvbscan  /usr/share/dvb/dvb-t/it-MyCity
> >>> Unable to query frontend status
> >>>
> >>> using a TerraTec Electronic GmbH with dvb-usb-dib0700 driver.
> >>>
> >>> The module seems to be loaded correctly, indeed I get this in the
> >>> kernel log:
> >>>
> >>> [ 1834.456051] dib0700: loaded with support for 7 different device-types
> >>> [ 1834.456051] dvb-usb: found a 'Terratec Cinergy HT USB XE' in cold state, will try to load a firmware
> >>> [ 1834.456051] firmware: requesting dvb-usb-dib0700-1.10.fw
> >>> [ 1834.464197] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.10.fw'
> >>> [ 1834.662979] dib0700: firmware started successfully.
> >>> [ 1835.168928] dvb-usb: found a 'Terratec Cinergy HT USB XE' in warm state.
> >>> [ 1835.168997] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
> >>> [ 1835.169355] DVB: registering new adapter (Terratec Cinergy HT USB XE)
> >>> [ 1835.419963] DVB: registering frontend 0 (DiBcom 7000PC)...
> >>> [ 1835.499932] xc2028 1-0061: creating new instance
> >>> [ 1835.499932] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner
> >>> [ 1835.499932] input: IR-receiver inside an USB DVB receiver as /class/input/input7
> >>> [ 1835.510406] dvb-usb: schedule remote query interval to 150 msecs.
> >>> [ 1835.510416] dvb-usb: Terratec Cinergy HT USB XE successfully initialized and connected.
> >>> [ 1835.510696] usbcore: registered new interface driver dvb_usb_dib0700
> >>>
> >>> The led on the device switched on when I performed the first scan.
> >>
> >> Other meaningful info:
> >> stefano at geppetto ~> dvbscan  /usr/share/dvb/dvb-t/it-Cagliari
> >> Unable to query frontend status
> >> stefano at geppetto ~> sudo dvbscan  /usr/share/dvb/dvb-t/it-Cagliari
> >> Unable to query frontend status
> >> stefano at geppetto ~> ls -l /dev/dvb/adapter0/
> >> total 0
> >> crw-rw---- 1 root video 212, 1 2008-09-23 00:04 audio0
> >> crw-rw---- 1 root video 212, 6 2008-09-23 00:04 ca0
> >> crw-rw---- 1 root video 212, 4 2008-09-23 00:04 demux0
> >> crw-rw---- 1 root video 212, 5 2008-09-23 00:04 dvr0
> >> crw-rw---- 1 root video 212, 3 2008-09-23 00:04 frontend0
> >> crw-rw---- 1 root video 212, 7 2008-09-23 00:04 net0
> >> crw-rw---- 1 root video 212, 8 2008-09-23 00:04 osd0
> >> crw-rw---- 1 root video 212, 0 2008-09-23 00:04 video0
> >>
> >> stefano at geppetto ~> uname -a
> >> Linux geppetto 2.6.26-1-686 #1 SMP Thu Oct 9 15:18:09 UTC 2008 i686 GNU/Linux
> >>
> >> The device is reported to be supported on the DVB wiki:
> >> http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_HT_USB_XE
> >>
> >> Help or hints will be appreciated.
> >>
> >> Regards.
> >
> > I believe I have seen a message like this when something else
> > is talking to the card already.  For instance, I run my cards in a Mythtv 
> > system, and in mythtv there is a setting to only attach to the card when 
> > actually using the card.  If that
> > setting is set incorrectly, mythtv will attach to the card at startup, 
> > and keep exclusive use of the card, not allowing
> > anyone else to access the card at all.
> 
> lsof didn't show any device accessing to device inside /dev/dvb.
> 
> But digging again in the web I found this:
> http://forums.opensuse.org/archives/sf-archives/archives-software/archives-multimedia/340016-dvb-t-card-cant-scan-10-3-a.html
> 
> So the problem seems a regression in the dvb-apps.
> 
> And precisely the problem seems to be in the function:
> libdvb/dvbfe.c:dvbfe_get_info()
> 
> Debugging I get this in dvbfe_get_info (second invocation during the
> running of the application):
> 
> dvbfe_get_info (fehandle=0x8beb008, 
>                querymask=DVBFE_INFO_LOCKSTATUS,
>                result=0xbfada108, 
>                querytype=DVBFE_INFO_QUERYTYPE_IMMEDIATE,
>                timeout=0) at dvbfe.c:23
> 
> 		if (querymask & DVBFE_INFO_LOCKSTATUS) {
> 			if (!ioctl(fehandle->fd, FE_READ_STATUS, &kevent.status)) {
> 				returnval |= DVBFE_INFO_LOCKSTATUS;
> 			}
> 		}
> 
> The result of the ioctl is 0 so the returnval is ored with
> DVBFE_INFO_LOCKSTATUS (so set to 1), then we have in the main:
> 
> 				if (dvbfe_get_info(fe, DVBFE_INFO_LOCKSTATUS, &feinfo,
> 				    			DVBFE_INFO_QUERYTYPE_IMMEDIATE, 0) !=
> 					DVBFE_INFO_QUERYTYPE_IMMEDIATE) {
> 					fprintf(stderr, "Unable to query frontend status\n");
> 					exit(1);
> 				}
> 
> 
> 
> which is different from DVBFE_INFO_QUERYTYPE_IMMEDIATE = 0, so the
> exit, but I can really understand the logic here.
> 
> So what's the expected exit of the ioctl with FE_READ_STATUS?

I read the log, and I see that apparently no changes has been
performed in the last two years on the affected code, so I tend to
believe that this isn't a regression in the utility but rather some
problem in the module/kernel.

So a pointer to the documentation of that ioctl would be nice,
meaninwhile I'll check for the w_scan application.

Thanks in advance, regards.



More information about the linux-dvb mailing list