[nmadrane]

I am using the latest version of VDR, vdr-plugin-dvbapi and VNSI. Everything works great with unencrypted channels. But when I try to zap to an encrypted channel I get the following log in VDR :

https://pastebin.com/FA68a5MJ

I asked the author of the vdr-plugin-dvbapi and he told me that the problem is in the following line :

"CA_PMT doesn't contain CA descriptors"

When I use TVHEADEND, it works : it connects to my OSCAM and succesfully decodes the stream. But the same OSCAM with VDR doesn't work. Actually this is not a problem of VDR/OSCAM connection. The problem is way before that : VDR has a problem decoding the CA_PMT stuff. The author of vdr-plugin-dvbapi that maybe the signal is bad. But I am using the same antenna in both cases (VDR and TVHEDEND), so this is not the problem.

Any idea please ?

[FernetMenta]

maybe you use an old version of vdr and the issue is long fixed. hard to tell because you did not provide enough info

[nmadrane]

Hi, thanks for your reply !

I am using VDR 2.2.0

[nmadrane]

I should also mention that I am using LIBREELEC, ported to K1 Plus and KII Pro by AFL.
AFL has developed the driver for AVL6882. This driver is not compatible with w_scan and VDR is not able to scan channels with this driver. So I am using a channels.conf files from the Internet (from http://channelpedia.yavdr.com).

So, the fact that the DVB driver is somehow incompatible with the scanning part of VDR could explain why I have this problem. Or is this a completely different issue ? As I said unencrypted channels work perfectly.

[FernetMenta]

2.2.0 is almost 3 years old. I would try a more recent version. As mentioned, the issue may have been fixed already.

[zbigzbig20]

Hi. I tested older vdr 2.2.0 on Wetek Play2 with LE based on Kodi Krypton 17.4 (@kszaq, @afl1 or @Raybuntu builds) And all channels (encrypted/fta) works ok. I am using my channels.conf (converted my hotbird 13e enigma2 settings into vdr format)

[nmadrane]

2.2.0 is almost 3 years old. I would try a more recent version. As mentioned, the issue may have been fixed already.

Oh I thought that 2.2.0 is the latest version according to http://www.tvdr.de/download.htm

[nmadrane]

2.2.0 is almost 3 years old. I would try a more recent version. As mentioned, the issue may have been fixed already.

I compiled VDR 2.3.8 (with corresponding vdr-plugin-dvbapi 2.3.8 and vdr-plugin-vnsiserver 2.3.8) and I have the same problem. I am lost.

Here is the log. It says somewhere :

"detaching receiver - won't decrypt channel S19.2E-1-1034-30680 with CAM 1"

Could anyone tell me if this is a connection problem with OSCAM or something different ?

Code:

Aug 29 20:40:46 LibreELEC vdr[30937]: [31071] VNSI: re-tuning...
Aug 29 20:40:46 LibreELEC vdr[30937]: [31071] VNSI: close video input ...
Aug 29 20:40:46 LibreELEC vdr[30937]: [31071] VNSI: re-tuning...
Aug 29 20:40:46 LibreELEC vdr[30937]: [31071] VNSI: close video input ...
Aug 29 20:40:46 LibreELEC vdr[30937]: [31071] VNSI: re-tuning...
Aug 29 20:40:46 LibreELEC vdr[30937]: [31071] VNSI: close video input ...
Aug 29 20:40:48 LibreELEC vdr[30937]: [31071] VNSI: exit streamer thread
Aug 29 20:40:48 LibreELEC vdr[30937]: [31071] cLiveStreamer stream processor thread ended (pid=30937, tid=31071)
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] VNSI: LiveStreamer::Close - close
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] VNSI: close video input ...
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] VNSI: close video input ...
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] VNSI: LiveStreamer::Close - close
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] VNSI: close video input ...
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] CAM 1: assigned to device 1
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] VNSI: Successfully found following device: 0xa7bba0 (1) for receiving, priority=0
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] VNSI: Dummy receiver (0xf1e24c38) activated
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] VNSI: activate live receiver: 1
Aug 29 20:40:48 LibreELEC vdr[30937]: [31083] device 1 receiver thread started (pid=30937, tid=31083, prio=high)
Aug 29 20:40:48 LibreELEC vdr[30937]: [31084] device 1 TS buffer thread started (pid=30937, tid=31084, prio=high)
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] DVBAPI: 0.0 CA_PMT decoding len=15 lm=4 prg=30680 len=0
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] DVBAPI: pid=2,00a8 len=0 (0x0)
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] DVBAPI: pid=4,0070 len=0 (0x0)
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] DVBAPI: pid=4,0071 len=0 (0x0)
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] DVBAPI: 0.0 got CA pmt ciCmd=-1 caLm=4
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] DVBAPI: 0.0 answer to query suppressed
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] DVBAPI: 0.0 set CAM decrypt (SID 30680 (0x77D8), caLm 4, HasCaDescriptors 0)
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] DVBAPI: CA_PMT doesn't contain CA descriptors
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] VNSI: Successfully switched to channel 460 - NAT GEO WILD
Aug 29 20:40:48 LibreELEC vdr[30937]: [31013] VNSI: Started streaming of channel NAT GEO WILD (timeout 10 seconds)
Aug 29 20:40:48 LibreELEC vdr[30937]: [31085] cLiveStreamer stream processor thread started (pid=30937, tid=31085, prio=high)
Aug 29 20:40:49 LibreELEC vdr[30937]: [30937] ERROR: no OSD provider available - using dummy OSD!
Aug 29 20:40:49 LibreELEC vdr[30937]: [31085] VNSI: Created stream for pid=168 and type=7
Aug 29 20:40:49 LibreELEC vdr[30937]: [31085] VNSI: Created stream for pid=112 and type=2
Aug 29 20:40:49 LibreELEC vdr[30937]: [31085] VNSI: Created stream for pid=113 and type=2
Aug 29 20:40:52 LibreELEC vdr[30937]: [31083] detaching receiver - won't decrypt channel S19.2E-1-1034-30680 with CAM 1
Aug 29 20:40:52 LibreELEC vdr[30937]: [31083] VNSI: activate live receiver: 0
Aug 29 20:40:52 LibreELEC vdr[30937]: [31083] DVBAPI: 0.0 CA_PMT decoding len=6 lm=5 prg=30680 len=0
Aug 29 20:40:52 LibreELEC vdr[30937]: [31083] DVBAPI: 0.0 got CA pmt ciCmd=-1 caLm=5
Aug 29 20:40:52 LibreELEC vdr[30937]: [31083] DVBAPI: 0.0 answer to query suppressed
Aug 29 20:40:52 LibreELEC vdr[30937]: [31083] DVBAPI: 0.0 set CAM decrypt (SID 30680 (0x77D8), caLm 5, HasCaDescriptors 0)
Aug 29 20:40:52 LibreELEC vdr[30937]: [31083] DVBAPI: 0.0 CA_PMT decoding len=6 lm=3 prg=0 len=0
Aug 29 20:40:52 LibreELEC vdr[30937]: [31083] DVBAPI: 0.0 got CA pmt ciCmd=-1 caLm=3
Aug 29 20:40:52 LibreELEC vdr[30937]: [31083] DVBAPI: 0.0 answer to query suppressed
Aug 29 20:40:52 LibreELEC vdr[30937]: [31083] DVBAPI: 0.0 stop decrypt
Aug 29 20:40:52 LibreELEC vdr[30937]: [31083] CAM 1: unassigned
Aug 29 20:40:52 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:40:52 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:40:52 LibreELEC vdr[30937]: [31085] VNSI: Dummy receiver (0xf1e24c38) deactivated
Aug 29 20:40:52 LibreELEC vdr[30937]: [31084] device 1 TS buffer thread ended (pid=30937, tid=31084)
Aug 29 20:40:52 LibreELEC vdr[30937]: [31083] buffer stats: 262316 (5%) used
Aug 29 20:40:52 LibreELEC vdr[30937]: [31083] device 1 receiver thread ended (pid=30937, tid=31083)
Aug 29 20:40:52 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:40:52 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:40:52 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:40:52 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:40:54 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:40:54 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:40:54 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:40:54 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:40:54 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:40:54 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:40:56 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:40:56 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:40:56 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:40:56 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:40:56 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:40:56 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:40:58 LibreELEC vdr[30937]: [31085] VNSI: Channel: no data 16
Aug 29 20:40:58 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:40:58 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:40:58 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:40:58 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:40:58 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:40:58 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:41:00 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:41:00 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:41:01 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:41:01 LibreELEC vdr[30937]: [31085] VNSI: close video input ...
Aug 29 20:41:01 LibreELEC vdr[30937]: [31085] VNSI: re-tuning...
Aug 29 20:41:01 LibreELEC vdr[30937]: [31085] VNSI: close video input ...

[zbigzbig20]

@nmadrane, if You can send me link to this vdr. I will check it on my wetek play2. It is similar box. On Play2 there was long time dvb driver problem with vdr but it is fixed now by @codesnake and vdr works

[nmadrane]

@nmadrane, if You can send me link to this vdr. I will check it on my wetek play2. It is similar box. On Play2 there was long time dvb driver problem with vdr but it is fixed now by @codesnake and vdr works

Hi zbigzbig20,

I am compiling from afl repository, version 8.0.1i : https://github.com/afl1/LibreELEC.tv/tree/8.0.1i


It uses VDR 2.2.0 : https://github.com/afl1/LibreELEC.tv/blo...package.mk

But as I said in my previous post, I also tested VDR 2.3.8 and I have the same problem. Could you please have a look at the log in my previous post ? Maybe it will give you an idea.

Thanks !

[zbigzbig20]

@nmadrane, better change vdr to Tvheadend backend. VDR now is not good choice for amlogic boxes. It works good on older wetek play but on newer play 2 is very unstable . Long time there was dvb driver problem with vdr. It is fixed but vdr still works not like should be . Tvheadend is much better choice now

[nmadrane]

@nmadrane, better change vdr to Tvheadend backend. VDR now is not good choice for amlogic boxes. It works good on older wetek play but on newer play 2 is very unstable . Long time there was dvb driver problem with vdr. It is fixed but vdr still works not like should be . Tvheadend is much better choice now

Thanks a lot for the advice, I will switch to TVHeadend.

[FernetMenta]

just for the record. vdr / vnsi is reference implementation for all streaming relevant features of pvr and video player