Build that includes media-build dvbsky drivers with working CI?

After finally getting a 4k TV i decided it was time to also switch from my pi3 to some 4k supporting hardware and got an odroid c2 …

I do run my system with DVBSky 960s and 960s-CI via vdr but it seems really hard to find an image that includes the drivers for it and still has some proper repos enabled (there are a good bunch of unofficial builds out there that include the drivers but then typically the addon repos are dead or outdated).

What was planned as a 1-2h task to switch HW and copy over data and settings turned out to be a super frustrating experience of 1 day jumping from image to image after which i eventually gave up … (note that i’m well able to build my own OS from source, i do that for a living, but exactly out of that reason i prefer to not having to do this also in my spare time (and i think i should not have to))

Is there any legal reason why these patches are missing in most builds or is it more a “it is extra work nobody wants to maintain” ? Could they be included by default in the CoreELEC images ? Or do i simply miss something here ?

Hi, did you notice the different DVB drivers under Addons -> LibreELEC Module Drivers? If the default doesn’t work try the DVB drivers for TBS (CrazyCat).

I haven’t verified though that DVBSky is part of CrazyCat driver package, but drivers for my card was included which I first thought was missing.

EDIT: Forgot to say my CI is not working though. I use tvheadend as backend and it looked to me like it was compiled with the necessary packages however the CI device is not visible under adapters. I haven’t had time to look into it more. Maybe its a driver issue.

Yup, i eventually discovered the CrazyCat drivers, though i found dvbsky actually comes with the hauppauge ones … but it seems even with them installed the kernel still loads the original dvb drivers alongside with them and in the end produces a mess (it seems to load m88ds3103 from the original kernel source along with dvb-usb-dvbsky from the hauppauge module addon):

CoreELEC:~ # dmesg|grep dvb
[    8.890466@1] kernel-overlays-setup: processing conf /storage/.cache/kernel-overlays/50-driver.dvb.hauppauge.conf
[    8.943172@1] kernel-overlays-setup: added modules from /usr/lib/kernel-overlays/driver.dvb.hauppauge/lib/modules/3.14.29
[   11.464943@2] usb 1-1.3: dvb_usb_v2: found a 'DVBSky S960/S860' in warm state
[   11.469070@1] usb 1-1.3: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[   11.469126@1] dvbdev: DVB: registering new adapter (DVBSky S960/S860)
[   11.470473@2] usb 1-1.3: dvb_usb_v2: MAC address: 00:17:42:54:96:0c
[   11.471635@2] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
[   11.489213@0] usb 1-1.3: dvbsky_s960_attach fail.
[   11.684946@0] usb 1-1.4: dvb_usb_v2: found a 'DVBSky S960CI' in warm state
[   11.687130@0] usb 1-1.4: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[   11.687188@0] dvbdev: DVB: registering new adapter (DVBSky S960CI)
[   11.688483@0] usb 1-1.4: dvb_usb_v2: MAC address: 00:18:42:54:96:0c
[   11.689544@0] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
[   11.691596@0] usb 1-1.4: dvbsky_s960ci_attach fail.
[   11.693955@0] usbcore: registered new interface driver dvb_usb_dvbsky

i also do not end up with a /dev/dvb dir in this case …

Sorry to hear it didn’t work out for you. There is a release coming soon which according to the change log has some dvb fixes, if you’re not in a rush.

1 Like

Yeah, i’m fine i’ll keep my pi running here until there is a working solution (i tend to not throw arm HW away once i bought it :wink: )… i’ll also try to start from a fresh image again before i give up, perhaps my tinkering broke something …

regarding CI, the limited CI capabilities were actually the reason that i picked VDR years ago (works fine with HD+ module as well as some other CAM i’m using here (not sure if we are allowed to mention CAMs here, so i’ll just keep it at “some CAM” :slight_smile: ) ), did tvheadend improve in that regard (i might give it a shot again, since it seems better maintained nowadays) ?

It has worked semi-succesfully for me in the past. As a matter of fact I used to run the same card with OSMC on a Raspberry PI 2b for a year or so. The CI+ with Conax HD+ CAM worked fine most of the time, however not with the OSMC store version of tvheadend 4.2 since they didn’t want to compile it with libdvben50221 support. I used an unofficial repo instead which worked well at that time.

Then OSMC upgraded to debian stretch which broke the CI again. I could never figure out why it wouldn’t work, the CI was visible but the decryption just did not work. I did notice later on tvheadend 4.3 (development version) worked, however it was so unstable I could not use.

The OSMC + Raspberry PI 2b combo was overall unstable for me but probably caused by the additional software (Webgrab++ etc.) and scripts I was running on it. I was out of memory constantly and the kodi or tvheadend process kept crashing so I jumped ship and bought a Mecool KIII Pro with Amlogic instead.

In terms of configuration TVHeadend is quite complicated but once you get the hang of it, it’s quite ok. It’s versatile though and has a lot of options. I can’t directly compare it to VDR since I have so little experience with it. I did try it at some point but I had some issue, which I can’t remember now. Maybe I’ll give it another go if I still have issues with the new release + tvheadend.

Greetings,

CI is very important for me, I have TBS 5880 and TBS 5990 USB Tuners, but I can not get any performance because it looks like an ordinary FTA in Amlogic based ELEC (OE, LE, CE does not notice) system.

This issue is really important, if solved Amlogic chip devices and ELEC will be much more popular.

Best regards…

First of all … i finally got it working with a re-flash and only installing CrazyCat … (which seemingly pulls in the hauppauge drivers too, i didnt pick them) …

vdr and oscam installed and configs copied from the Pi …

… and you are correct … CI doesnt work (everything else does ! i can watch all free HD channels)
there seems to be some serious issue with the DVBAPI … (i see a good amount of spam in journalctl)

i kind of got dragged away into trying to get audio with my receiver to work through my Xonar U7 (S/PDIF) which requires some special treatment, so i didnt dig deeper into the DVBAPI bits yet (probably something for the weekend)

In any case, thanks a lot for the hand-holding :slight_smile:

I hope you noticed the newly released version 8.90.3. I didn’t realize from your earlier post that you were using soft cam. I have a HW cam and my issue is that the entire CA adapter is not visible in my backend. (Although it exists under /dev/dvb/adapter1/ca0)

On my Pi I have the CA adapter visible but otherwise I have the same issue as you, decryption doesn’t work.

I think you could try a command line tool like dvblast record some encrypted channel, transfer it over to you pc and see if that works in case you suspect the issue is with VDR. However if the same config+setup works on your Pi it’s a bit far fetched.

Yes, I got the update and the system auto-updated to .3 just fine …

I got the same device nodes here with the dvbsky S960CI but vdr needs oscam to actually talk to the CA device (i also had some hope to eventually abuse the CA via oscam to share it with the S960 to eventually be able to record and view encrypted stations at the same time but i guess thats not possible with a builtin CA)

The setup (and config) used to work on the Pi on LE8 (I’m in fact now switching boards between the USB plugs back and forth)

CoreELEC:~ # ls /dev/dvb/adapter?/
/dev/dvb/adapter0/:
ca0        demux0     dvr0       frontend0  net0

/dev/dvb/adapter1/:
demux0     dvr0       frontend0  net0

The CA is definitely found by the driver and also initialized:

CoreELEC:~ # dmesg|grep dvb
[    8.940071@0] kernel-overlays-setup: processing conf /storage/.cache/kernel-overlays/50-driver.dvb.crazycat.conf
[    9.006884@0] kernel-overlays-setup: added modules from /usr/lib/kernel-overlays/driver.dvb.crazycat/lib/modules/3.14.29
[   11.293222@0] usb 1-1.3: dvb_usb_v2: found a 'DVBSky S960CI' in warm state
[   11.293824@2] usb 1-1.3: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[   11.293879@2] dvbdev: DVB: registering new adapter (DVBSky S960CI)
[   11.295175@2] usb 1-1.3: dvb_usb_v2: MAC address: 00:18:42:54:96:0c
[   11.473223@1] Registered IR keymap rc-dvbsky
[   11.480283@1] usb 1-1.3: dvb_usb_v2: schedule remote query interval to 300 msecs
[   11.480304@1] usb 1-1.3: dvb_usb_v2: 'DVBSky S960CI' successfully initialized and connected
[   11.673204@2] usb 1-1.4: dvb_usb_v2: found a 'DVBSky S960/S860' in warm state
[   11.678009@2] usb 1-1.4: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[   11.678081@2] dvbdev: DVB: registering new adapter (DVBSky S960/S860)
[   11.679419@2] usb 1-1.4: dvb_usb_v2: MAC address: 00:17:42:54:96:0c
[   11.748125@2] Registered IR keymap rc-dvbsky
[   11.750215@0] usb 1-1.4: dvb_usb_v2: schedule remote query interval to 300 msecs
[   11.750234@0] usb 1-1.4: dvb_usb_v2: 'DVBSky S960/S860' successfully initialized and connected
[   11.751311@0] usbcore: registered new interface driver dvb_usb_dvbsky
[   12.962391@2] m88ds3103 0-0068: downloading firmware from file 'dvb-demod-m88ds3103.fw'
[   13.997397@2] m88ds3103 3-0068: downloading firmware from file 'dvb-demod-m88ds3103.fw'
[   14.201571@2] dvb_ca_en50221: dvb_ca adapter 0: DVB CAM detected and initialised successfully

This is the output i see when switching to an encrypted station:

Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: 0.0 CA_PMT decoding len=230 lm=5 prg=61204 len=22a
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: ci_cmd(G)=04
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: 0.0 got CA pmt ciCmd=4 caLm=5
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: 0.0 answer to query suppressed
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: 0.0 stop decrypt
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: 0.0 CA_PMT decoding len=6 lm=3 prg=0 len=0
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: 0.0 got CA pmt ciCmd=-1 caLm=3
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: 0.0 answer to query suppressed
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: 0.0 stop decrypt
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: ProcessSIDRequest: got empty SID - returning from function
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: 0.0 CA_PMT decoding len=23f lm=4 prg=61204 len=22a
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: ci_cmd(G)=01
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: pid=2,04ff len=0 (0x0)
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: pid=6,0503 len=0 (0x0)
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: pid=6,0504 len=0 (0x0)
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: 0.0 got CA pmt ciCmd=1 caLm=4
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: 0.0 answer to query suppressed
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: 0.0 set CAM decrypt (SID 61204 (0xEF14), caLm 4, HasCaDescriptors 1)
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: send: channelSid=0xef14 (61204)
Jun 08 15:36:07 CoreELEC vdr[4318]: [4402] DVBAPI: Write, sock=0
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: OSCam not connected, (re)connecting...
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: created socket with socket_fd=54
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: Successfully (re)connected to OSCam
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: Write, sock=54
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: socket_fd=54 len=69 wrote=69
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: send: channelSid=0xef14 (61204)
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: Write, sock=54
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: socket_fd=54 len=585 wrote=585
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: Action: Got SERVER_INFO: OSCam v1.20-unstable_svn, build r11420 (armv8a-libreelec-linux-gnueabi); , protocol_version = 3
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: Action: Got DMX_SET_FILTER request, adapter_index=0, pid=0, demux_idx=0, filter_num=0
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: SetFilter: adapter=0 set FILTER pid=0000 start=1, demux=0, filter=0
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI:    --> FILTER: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI:    -->   MASK: FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: SetFilter: inserting new filter, demux=0, filter_num=0
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: Action: Got DMX_SET_FILTER request, adapter_index=0, pid=1, demux_idx=0, filter_num=1
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: SetFilter: adapter=0 set FILTER pid=0001 start=1, demux=0, filter=1
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI:    --> FILTER: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI:    -->   MASK: FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI: SetFilter: inserting new filter, demux=0, filter_num=1
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 002b6f3c
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 01000100
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 00000000
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 00000000
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 00000000
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: ff000000
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 00000000
Jun 08 15:36:07 CoreELEC vdr[4318]: [4403] DVBAPI: Analyze: all data in one TS packet, immediate send
Jun 08 15:36:07 CoreELEC vdr[4318]: [4403] DVBAPI: Write, sock=54
Jun 08 15:36:07 CoreELEC vdr[4318]: [4403] DVBAPI: socket_fd=54 len=118 wrote=118
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 00000000
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 00000000
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 00000000
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 00000000
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 00000000
Jun 08 15:36:07 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 00000004
Jun 08 15:36:08 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 00000000
Jun 08 15:36:08 CoreELEC vdr[4318]: [4360] DVBAPI-Error: Action: read failed unknown command: 2a000001
Jun 08 15:36:08 CoreELEC vdr[4318]: [4403] DVBAPI: Analyze: all data in one TS packet, immediate send
Jun 08 15:36:08 CoreELEC vdr[4318]: [4403] DVBAPI: Write, sock=54
Jun 08 15:36:08 CoreELEC vdr[4318]: [4403] DVBAPI: socket_fd=54 len=118 wrote=118
Jun 08 15:36:08 CoreELEC vdr[4318]: [4403] DVBAPI: Analyze: all data in one TS packet, immediate send
Jun 08 15:36:08 CoreELEC vdr[4318]: [4403] DVBAPI: Write, sock=54
Jun 08 15:36:08 CoreELEC vdr[4318]: [4403] DVBAPI: socket_fd=54 len=118 wrote=118
Jun 08 15:36:09 CoreELEC vdr[4318]: [4403] DVBAPI: Analyze: all data in one TS packet, immediate send
Jun 08 15:36:09 CoreELEC vdr[4318]: [4403] DVBAPI: Write, sock=54
Jun 08 15:36:09 CoreELEC vdr[4318]: [4403] DVBAPI: socket_fd=54 len=118 wrote=118
Jun 08 15:36:09 CoreELEC vdr[4318]: [4403] DVBAPI: Analyze: all data in one TS packet, immediate send
Jun 08 15:36:09 CoreELEC vdr[4318]: [4403] DVBAPI: Write, sock=54
Jun 08 15:36:09 CoreELEC vdr[4318]: [4403] DVBAPI: socket_fd=54 len=118 wrote=118
Jun 08 15:36:10 CoreELEC vdr[4318]: [4403] DVBAPI: Analyze: all data in one TS packet, immediate send
Jun 08 15:36:10 CoreELEC vdr[4318]: [4403] DVBAPI: Write, sock=54
Jun 08 15:36:10 CoreELEC vdr[4318]: [4403] DVBAPI: socket_fd=54 len=118 wrote=118
Jun 08 15:36:10 CoreELEC vdr[4318]: [4403] DVBAPI: Analyze: all data in one TS packet, immediate send
Jun 08 15:36:10 CoreELEC vdr[4318]: [4403] DVBAPI: Write, sock=54
Jun 08 15:36:10 CoreELEC vdr[4318]: [4403] DVBAPI: socket_fd=54 len=118 wrote=118
Jun 08 15:36:11 CoreELEC vdr[4318]: [4403] DVBAPI: Analyze: all data in one TS packet, immediate send
Jun 08 15:36:11 CoreELEC vdr[4318]: [4403] DVBAPI: Write, sock=54
Jun 08 15:36:11 CoreELEC vdr[4318]: [4403] DVBAPI: socket_fd=54 len=118 wrote=118
Jun 08 15:36:12 CoreELEC vdr[4318]: [4403] DVBAPI: Analyze: all data in one TS packet, immediate send
Jun 08 15:36:12 CoreELEC vdr[4318]: [4403] DVBAPI: Write, sock=54
Jun 08 15:36:12 CoreELEC vdr[4318]: [4403] DVBAPI: socket_fd=54 len=118 wrote=118
Jun 08 15:36:13 CoreELEC vdr[4318]: [4403] DVBAPI: Analyze: all data in one TS packet, immediate send
Jun 08 15:36:13 CoreELEC vdr[4318]: [4403] DVBAPI: Write, sock=54
Jun 08 15:36:13 CoreELEC vdr[4318]: [4403] DVBAPI: socket_fd=54 len=118 wrote=118
Jun 08 15:36:13 CoreELEC vdr[4318]: [4360] DVBAPI: Action: Got DMX_SET_FILTER request, adapter_index=0, pid=11, demux_idx=0, filter_num=1
Jun 08 15:36:13 CoreELEC vdr[4318]: [4360] DVBAPI: SetFilter: adapter=0 set FILTER pid=0011 start=1, demux=0, filter=1

I’ll compare the app versions of vdr and oscam between the two installs on the weekend when i have a little more time to tinker with this …

Just as a FYI … i tried with the same userspace versions of vdr and oscam that i use on the LibreELEC Pi, with identical config and am now sure that this is a kernel or driver issue. For the moment i resorted to vdr-streamdev so i can leave the cards in the Pi and the CoreELEC odroid can use them like actual local dvb devices over the network.

This is indeed not a permanent solution (channel switching times are hilarious in this setup) and it would be good to know if we perhaps have a general CI problem here… i wonder if there is anyone in this forum who has actually working CI HW with the current media-build drivers …

Would be nice to hear from somebody else for sure.

I also has some spare time during the weekend and played around with my setup

mecool:~ # ls /dev/dvb/adapter?/
/dev/dvb/adapter0/:
demux0     demux2     dvr1       frontend0  net1
demux1     dvr0       dvr2       net0       net2

/dev/dvb/adapter1/:
ca0        demux0     dvr0       frontend0  net0
mecool:~ #

Adapter 0 is my built-in Availink and adapter1 is my TechnoTrend CT2-4650 which has the CI slot.

This is how the TT adapter looks using Hauppauge drivers.

[155374.818934@7] usb 1-1.4: new high-speed USB device number 8 using xhci-hcd
[155374.919248@6] usb 1-1.4: New USB device found, idVendor=0b48, idProduct=3015
[155374.919269@6] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[155374.919281@6] usb 1-1.4: Product: TechnoTrend USB2.0
[155374.919292@6] usb 1-1.4: Manufacturer: CityCom GmbH
[155374.919303@6] usb 1-1.4: SerialNumber: 2015xxxx
[155375.118682@6] usb 1-1.4: dvb_usb_v2: found a 'TechnoTrend TT-connect CT2-4650 CI v1.1' in warm state
[155375.119305@6] usb 1-1.4: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[155375.119364@6] dvbdev: DVB: registering new adapter (TechnoTrend TT-connect CT2-4650 CI v1.1)
[155375.119381@6] usb 1-1.4: media controller created
[155375.120637@6] usb 1-1.4: dvb_usb_v2: MAC address: xx:xx:xx:xx:xx:xx
[155375.122664@6] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
[155375.137178@6] i2c i2c-5: Added multiplexed i2c bus 6
[155375.137202@6] si2168 5-0064: Silicon Labs Si2168-B40 successfully identified
[155375.137214@6] si2168 5-0064: firmware version: B 4.0.2
[155375.142294@7] si2157 6-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached
[155375.150910@7] dvbdev: dvb_create_media_entity: media entity 'dvb-ca-en50221' registered.
[155375.151362@7] sp2 5-0040: CIMaX SP2 successfully attached
[155375.151407@7] usb 1-1.4: DVB: registering adapter 1 frontend 0 (Silicon Labs Si2168)...
[155375.151430@7] dvbdev: dvb_create_media_entity: media entity 'Silicon Labs Si2168' registered.
[155375.153313@7] Registered IR keymap rc-tt-1500
[155375.153537@7] rc rc1: TechnoTrend TT-connect CT2-4650 CI v1.1 as /devices/c9000000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.4/rc/rc1
[155375.153843@7] input: TechnoTrend TT-connect CT2-4650 CI v1.1 as /devices/c9000000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.4/rc/rc1/input11
[155375.154340@7] rc rc1: lirc_dev: driver dvb_usb_dvbsky registered at minor = 1
[155375.154361@7] usb 1-1.4: dvb_usb_v2: schedule remote query interval to 300 msecs
[155375.154380@7] usb 1-1.4: dvb_usb_v2: 'TechnoTrend TT-connect CT2-4650 CI v1.1' successfully initialized and connected
[155852.534483@0] si2168 5-0064: downloading firmware from file 'dvb-demod-si2168-b40-01.fw'
[155853.913876@5] si2168 5-0064: firmware version: B 4.0.19
[155853.927909@5] si2157 6-0060: found a 'Silicon Labs Si2157-A30'
[155853.979675@5] si2157 6-0060: firmware version: 3.0.5

It all seems great, even after I insert the CAM in the CI slot it says

[160926.122994@4] dvb_ca_en50221: dvb_ca adapter 1: DVB CAM detected and initialised successfully

But this is where it gets a bit tricky. There is a “known issue” with my CAM, where I have to initialize it using gnutv from dvb-apps. (Also stated on LinuxTV) With CAM inserted I cannot even watch FTA channels and if I insert it while watching FTA, the signal just dies.

Usually gnutv is part of the dvb-apps package but for whatever reason it’s not part of the dvb-apps package included in the CE DVB Tools addon. I managed to get hold of a copy so I ran it. The output is what I expect it to be but that made no difference at all.

Using frontend “Silicon Labs Si2168”, type DVB-C
status SCVYL | signal 7332 | snr 0159 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

I then ran an strace and gnutv again and noticed this error

ioctl(3, CA_GET_SLOT_INFO, 0xff8d2498) = -1 ENOTTY (Inappropriate ioctl for device)

I suspected my binary might bad since i copied it over from elswhere so I thought I’d tried the other binaries in the CE DVB Tools addon. But while running dvblast I get the same error

error: failed getting CAM capabilities (Inappropriate ioctl for device)

And with tvheadend the error is

2018-06-10 22:18:06.080 [ ERROR] linuxdvb: unable to query /dev/dvb/adapter1/ca0

Back in the day the card was not supported by OSMC and I used to compile my own version of media build. I was thinking of doing the same now but cross-compiling seems to be whole 'nother ball game.

I noticed that running tvheadend in a docker container makes the CA visible and also the decryption works. I still need to figure out how to fix iptv but it’s probably not a big issue.

There seems to be an oscam docker container available as well on linuxserver.io, maybe it’ll fix your issue.

if there is interest I can write a small guide, but I’m away rest of the week so it’ll have to wait until next week.

Thanks for that !

I’m not a fan of docker containers, especially on constrained hardware, but your finding adds an interesting data point. Since the container uses the same kernel as the host OS, it can not actually be a kernel issue but must be something missing in user space. Comparing the set of libraries shipped in both to find what’s missing in the CoreELEC build might get us a step forward.

Even though I personally am not interested in using docker, others might be so a HOWTO is surely very helpful for someone :wink: . I’ll start taking a look at the library differences on (or around) the weekend (I don’t want to accidentially trash my working setup while watching the world cup though :slight_smile: ).

(I added CI to the topic to make it easier to find it for someone searching the forum)

Greetings,

For me, the greatest feature and the biggest problem is that the CI Feature is not working and the problem is not solved.

If the CI feature works, believe that these devices and USB-Tuners will be in vogue.

I will be very, very happy if this issue is resolved.

Best regards…

Greetings,

Is there still no improvement in this regard? :frowning:

Best regards…