MythTV Backend Setup Doesn't recognise DVBSky S952

[cl@…]

Hello,

I have installed a DVBSky S952 in my server, installed the driver from dvbsky, been able to use the scan command on astra 19.2, but when I try to declare the card in myth backend, it says: Could not get card info for card /dev/dvb...

And unkown error in Subtype.

lsof | grep dvb tells me noone use it.

But in the log I have :

Jun 13 00:59:08 hestia mythtv-setup[3135]: E CoreContext cardutil.cpp:414 (ProbeDVBType) FE_GET_INFO ioctl failed (/dev/dvb/adapter0/frontend0)
			eno: No such device (19)

but has seen in dmesg :

[    4.769102] cx23885 driver version 0.0.3 loaded
[    4.769202] cx23885 0000:0a:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[    4.769476] CORE cx23885[0]: subsystem: 4254:0952, board: DVBSKY S952 [card=36,autodetected]
[    5.012730] cx25840 6-0044: cx23885 A/V decoder found @ 0x88 (cx23885[0])
[    5.408460] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[    5.514228] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[    5.530599] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
[    5.694815] cx25840 6-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes)
[    5.728435] cx23885_dvb_register() allocating 1 frontend(s)
[    5.728439] cx23885[0]: cx23885 based dvb card
[    5.748028] DS3000 chip version: d0 attached.
[    5.748838] TS202x chip version[1]: 80 attached.
[    5.772838] TS202x chip version[2]: 81 attached.
[    5.810274] EXT4-fs (sda7): mounted filesystem with ordered data mode. Opts: (null)
[    5.812376] m88ds3103_load_firmware: Waiting for firmware upload (dvb-fe-ds3103.fw)...
[    5.921033] m88ds3103_load_firmware: Waiting for firmware upload(2)...

[    6.818539] DVB: registering new adapter (cx23885[0])
[    6.818544] DVB: registering adapter 0 frontend 0 (Montage DS3103/TS2022)...
[    6.819072] cx23885_dvb_register() allocating 1 frontend(s)
[    6.819075] cx23885[0]: cx23885 based dvb card
[    6.819564] DS3000 chip version: d0 attached.
[    6.820347] TS202x chip version[1]: 80 attached.
[    6.840834] TS202x chip version[2]: 81 attached.
[    6.872390] m88ds3103_load_firmware: Waiting for firmware upload (dvb-fe-ds3103.fw)...
[    6.873999] m88ds3103_load_firmware: Waiting for firmware upload(2)...

[    7.773110] DVB: registering new adapter (cx23885[0])
[    7.773114] DVB: registering adapter 1 frontend 0 (Montage DS3103/TS2022)...
[    7.773587] cx23885_dev_checkrevision() Hardware revision = 0xa5
[    7.773593] cx23885[0]/0: found at 0000:0a:00.0, rev: 4, irq: 17, latency: 0, mmio: 0xd5c00000
[    7.773685] cx23885 0000:0a:00.0: setting latency timer to 64

mythbackend version: fixes/0.25 [v0.25.1-2-g648f0ae]

any idea ?

[Raymond Wagner]

Cleanup. Resetting defaults.

[Raymond Wagner]

Could we see the full mythtv-setup log, and not just this one snippet? The terminal or file logs would be preferable to what gets filtered and reformatted through syslog.

[cl@…]

mythtv-setup.log

[cl@…]

Replying to wagnerrp:

Could we see the full mythtv-setup log, and not just this one snippet? The terminal or file logs would be preferable to what gets filtered and reformatted through syslog.

Here it is, the syslog, and the log ( in case ... )

produce by :

mythtv-setup.real --loglevel debug --logpath logs/

I have been able to declare the second tuner ! First time it has been possible, unfortunatly I haven't grab it in the logs ( misconfiguration :( )

Openelec seems to make it work through a special option, "Wait for initialisation".

[cl@…]

myth-setup.real --loglevel debug --logpath logs/

[dekarl@…]

I suspect a bug in the DVB frontend-core driver, but I did not have time to analyze it yet. myth-setup has a (unnecessary) open, ioctl, close, open, ioctl, close cycle when looking up the DVB frontends that might trigger a race condition.

Seeing a truss log would be good. (e.g. run "truss myth-setup.real" then try to add the card) To work around you can try running femon on the frontend that you want to setup.

[dekarl@…]

Sorry, "truss" is called "strace" in Linux.

[cl@…]

Replying to dekarl@…:

Sorry, "truss" is called "strace" in Linux.

The second tuner seems to work, I have been able to scan the channels. I suspect that if I am able to connect the first tuner to a lnb ( in the software ) it will also for the first. Because when I try to scan on the first tuner, it goes to the dvb-s scanner type. But then there is an error.

I will do a strace tonight, need to go.

How femon can help me ?

[dekarl@…]

Replying to cl@…:

How femon can help me ?

if the issure is the suspect race when closing and directly reopening the frontend device, then femon will help by keeping the frontend open so the driver does not shut down the hardware.

[warpme@…]

Hi, sorry for "me too", but I think issue is within mythv-setup. Recently I added S952 to production BE (sys has already 2x ptg7301) and spent hours trying to setup (some details are here ​http://www.gossamer-threads.com/lists/mythtv/users/523671#523671). Interesting is that in my test system I was able to configure S952 - but usually after some tries. I think it is result of regression in mythtv-setup as in my production system (with 5 tuners) I also wasn't able to recreate entries for ptg7301, but - again - the same single ptg7301 in test system:no problem. Also no problem with ptg7301 in production system before adding S952. BTW: also look here: ​http://www.gossamer-threads.com/lists/mythtv/dev/513410#513410

[danielk]

"FE_GET_INFO ioctl failed" == driver bug or user error

[dekarl@…]

Here are links to upstream in case you want to help out there or just see if it fixes your issue.

A fix for the driver has been proposed over at LinuxTV, see ​http://patchwork.linuxtv.org/patch/13563/

The relevant discussion starts at ​http://www.spinics.net/lists/linux-media/msg51045.html

Testing is appreciated, like "remove an USB device by hand while tuning it, and see if the core will not lock the device forever."

[warpme@…]

Karl, FYI: I tested 3.3.8 + [​​http://patchwork.linuxtv.org/patch/13563/] and 5 different tuners. It works OK ! Thx.

[cl@…]

Replying to dekarl@…:

Here are links to upstream in case you want to help out there or just see if it fixes your issue.

A fix for the driver has been proposed over at LinuxTV, see ​http://patchwork.linuxtv.org/patch/13563/

The relevant discussion starts at ​http://www.spinics.net/lists/linux-media/msg51045.html

Testing is appreciated, like "remove an USB device by hand while tuning it, and see if the core will not lock the device forever."

Basic tests are ok ( ubuntu 12.04, linux 3.2.0-26, media_build-3.3.x.tar.gz from dvbsky ) . I use an old driver from dvbsky because I also have 4 dib7000 on usb and with the latest driver from dvbsky, with or without your patch ( and with femon in that case ) I can not lock some multiplex while others are working. The s952 in that case seems to operate properly ( 10 minutes test ).

I will do some more extensive usb tests on the dib7000 shortly.

[J.Pilk@…]

I'm still seeing this with Fedora 16 kernel 3.6.2-1. Don't know why no patch has been accepted yet. However, it does seem (as suggested above) that running femon -H -aX, where X is the adapter number, while trying to get card info in mythtvsetup, will allow things to go forward. It's fragile, though, and I'm reluctant to push it harder.

My initial report was #11085, with no link in the title to a specific card.

[anonymous@…]

Just to let you guys know: I am using the latest drivers from DVBSky (media_build_bst-121013.tar.gz) with MythBuntu? 12.04 (mythtv 0.25), and they work flawlessly out of the box.

Both tuners are recognized and channel scan in mythtv works, so it appears that DVBSky did some kind of driver level fix/workaround for this issue.

[inbox73pe@…]

I'm using 3.3.8 and still have the problem. I'm using a PCI DVB tuner card.

The workaround with femon worked and therefore it would be great if mythtv setup print a message that it could be a driver bug and a link to this page.

[b-eckl@…]

"Running femon -H -aX, where X is the adapter number, while trying to get card info in mythtvsetup, will allow things to go forward."

GREAT help! Works for me! Hours spent, now works, thanks so much!

[borgeh@…]

femon -H -a1 was the perfect way to get HVR-4000 up and running, both in archlinux and Kubuntu 12.10, x64 and kernel 3.5. That solved more than a years worth of headache, thanks.