gerald Ich hab' mal bei vtuner-ng develop die Prototypen für param_set_hex und param_get_hex hinzugefügt. Sollte nun keine "Fehler" mehr geben.
Posts by Joe_D
-
-
-
the same problem with "develop" vtuner_proxyca.c
I'm using Ubuntu 22.04.5 and get no errors:
Code
Display Moremake -C /lib/modules/5.15.0-153-generic/build M=/usr/src/github/vtuner-ng/kernel modules make[1]: Entering directory '/usr/src/linux-headers-5.15.0-153-generic' warning: the compiler differs from the one used to build the kernel The kernel was built by: gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 You are using: gcc (Ubuntu 11.4.0-1ubuntu1~22.04.2) 11.4.0 make[2]: *** /usr/src/linux: No such file or directory. Stop. CC [M] /usr/src/github/vtuner-ng/kernel/vtunerc_main.o CC [M] /usr/src/github/vtuner-ng/kernel/vtunerc_ctrldev.o CC [M] /usr/src/github/vtuner-ng/kernel/vtunerc_proxyfe.o CC [M] /usr/src/github/vtuner-ng/kernel/vtunerc_proxyca.o LD [M] /usr/src/github/vtuner-ng/kernel/vtunerc.o make[2]: *** /usr/src/linux: No such file or directory. Stop. MODPOST /usr/src/github/vtuner-ng/kernel/Module.symvers CC [M] /usr/src/github/vtuner-ng/kernel/vtunerc.mod.o LD [M] /usr/src/github/vtuner-ng/kernel/vtunerc.ko BTF [M] /usr/src/github/vtuner-ng/kernel/vtunerc.ko Skipping BTF generation for /usr/src/github/vtuner-ng/kernel/vtunerc.ko due to unavailability of vmlinux make[1]: Leaving directory '/usr/src/linux-headers-5.15.0-153-generic' cp vtunerc.ko /lib/modules/5.15.0-153-generic/kernel/drivers/media/tuners depmod -a 5.15.0-153-genericEven with 13.1.0 no errors:
Code
Display Moremake -C /lib/modules/5.15.0-153-generic/build M=/usr/src/github/vtuner-ng/kernel modules make[1]: Entering directory '/usr/src/linux-headers-5.15.0-153-generic' warning: the compiler differs from the one used to build the kernel The kernel was built by: gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 You are using: gcc (Ubuntu 13.1.0-8ubuntu1~22.04) 13.1.0 make[2]: *** /usr/src/linux: No such file or directory. Stop. CC [M] /usr/src/github/vtuner-ng/kernel/vtunerc_main.o CC [M] /usr/src/github/vtuner-ng/kernel/vtunerc_ctrldev.o CC [M] /usr/src/github/vtuner-ng/kernel/vtunerc_proxyfe.o CC [M] /usr/src/github/vtuner-ng/kernel/vtunerc_proxyca.o LD [M] /usr/src/github/vtuner-ng/kernel/vtunerc.o make[2]: *** /usr/src/linux: No such file or directory. Stop. MODPOST /usr/src/github/vtuner-ng/kernel/Module.symvers CC [M] /usr/src/github/vtuner-ng/kernel/vtunerc.mod.o LD [M] /usr/src/github/vtuner-ng/kernel/vtunerc.ko BTF [M] /usr/src/github/vtuner-ng/kernel/vtunerc.ko Skipping BTF generation for /usr/src/github/vtuner-ng/kernel/vtunerc.ko due to unavailability of vmlinux make[1]: Leaving directory '/usr/src/linux-headers-5.15.0-153-generic' -
BTW, what documentation are you using?
https://download.digital-devices.eu/download/dokum…onet_ci_en.html
[Dynamic ADDPID and DELPID with CI support (channel switching) with unknown PMT-PID] -
shows the right pmt
The only relevant Info are the cam lines.
If there is a 0-PMT something is wrongPlease forget the pid tab. Those are the pids which i get from vdr - If there is a PMT in this list it has nothing to do with the pmt sent to the satip program…
That is a bug
seems left after some debuggingA bug in the documentation?
-
-
-
Hier ist noch ein Dokument, was die Interaktion mit dem CI erklärt:
Hab' ich mir nun auch mal angeschaut. Also dämlicher kann man das ganze wohl nicht gestalten

Anstatt einfach ein CI dynamisch zu belegen bei addpids=1920,1921,0,107,1925&x_pmt=107 muss schon "vorher" das CI auf dem Stream "festgenagelt" werden mit x_pmt=0
Da frage ich mich dann wenn über diesen Stream etwas unverschlüsseltes aufgenommen wird, ist das CI dann dauerblockiert? Oder hilft hier die Device-Auswahl im vdr das zu verhindern?
Lustigerweise wurde vergessen eine Möglichkeit zu schaffen das CI von einem Stream wieder zu "entnageln", z.B. mit x_ci=0 oder x_pmt=-1 - so wie es aussieht muss das CI mit einem Teardown gekickt werden. Bislang erstellt das satip-Programm einen Stream der erst abgebaut wird wenn der VDR ihn nicht mehr verwendet. Bei Live-Fernsehen also nie. Die rasanten Umschaltzeiten haben mich darin bestätigt.
Und auch so Vorgaben wie "use the following sequence exactly as specified" mit der obligatorischen Vorgabe die pmt-Pid als letztes zu entfernen ... wer kommt denn auf sowas??
Ich könnte meine OctopusNet für weitere Tests zur Verfügung stellen. Hilft das was?
Denke schon, musst dann aber auch vtuner aufsetzen...
-
-
-
the_man Sorry, i introduced a bug ...
-
I'm just not sure if Joe_D has already integrated all the possibilities into vtuner-ng code / git?
I included all code to be able to switch to decoded channels. And that works pretty good! I don't have any decryption hardware, so i can't do any further codings...
What i'm not able to test and what the_man should do is to extend the satip program in a way that the transmitted pmt-pid gets send out in a proper way. -
The vTuner CAID is independent of the real CAID. This can only cause problems if the selected vTuner CAID is "removed" due to an update. If I use CAID 0x98C, I can "switch" to 160 channels. With CAID 0x186a, it's 53. Whether these can be decoded is still determined by the "physical CAM." To avoid timeouts, there is the option to specify individual SIDs, which allows for pre-filtering.
With 0x98C is switch to ORF1Code
Display MoreAug 31 09:09:41 vdr vdr: [3309] switching to channel 1120 S19.2E-1-1007-4911 (ORF1 HD) Aug 31 09:09:41 vdr vdr: [3309] CAM 1: assigned to device 1 Aug 31 09:09:42 vdr vdr: [3308] device 1 TS buffer thread ended (pid=3300, tid=3308) Aug 31 09:09:42 vdr vdr: [3307] buffer stats: 1780924 (10%) used Aug 31 09:09:42 vdr vdr: [3307] device 1 receiver thread ended (pid=3300, tid=3307) Aug 31 09:09:42 vdr vdr: [3417] device 1 receiver thread started (pid=3300, tid=3417, prio=high) Aug 31 09:09:42 vdr vdr: [3418] device 1 TS buffer thread started (pid=3300, tid=3418, prio=high) Aug 31 09:09:42 vdr vdr: [3309] SVDRP vdr < 127.0.0.1:36182 connection closed Aug 31 09:09:42 vdr vdr: [3309] SVDRP vdr < 127.0.0.1:36182 server destroyed Aug 31 09:09:44 vdr vdr: [3300] retuning due to modification of channel 1120 (ORF1 HD) Aug 31 09:09:44 vdr vdr: [3300] switching to channel 1120 S19.2E-1-1007-4911 (ORF1 HD) Aug 31 09:09:44 vdr vdr: [3300] CAM 1: unassigned from device 1 Aug 31 09:09:44 vdr vdr: [3300] CAM 1: assigned to device 1 Aug 31 09:09:44 vdr vdr: [3418] device 1 TS buffer thread ended (pid=3300, tid=3418) Aug 31 09:09:44 vdr vdr: [3417] buffer stats: 160364 (0%) used Aug 31 09:09:44 vdr vdr: [3417] device 1 receiver thread ended (pid=3300, tid=3417) Aug 31 09:09:44 vdr vdr: [3419] device 1 receiver thread started (pid=3300, tid=3419, prio=high) Aug 31 09:09:44 vdr vdr: [3420] device 1 TS buffer thread started (pid=3300, tid=3420, prio=high)And i switch to Prosieben HD:
Code
Display MoreAug 31 09:12:09 vdr vdr: [3309] switching to channel 1127 S19.2E-1-1017-61301 (ProSieben HD) Aug 31 09:12:09 vdr vdr: [3309] CAM 1: assigned to device 1 Aug 31 09:12:09 vdr vdr: [3464] device 1 TS buffer thread ended (pid=3300, tid=3464) Aug 31 09:12:09 vdr vdr: [3463] buffer stats: 0 (0%) used Aug 31 09:12:09 vdr vdr: [3463] device 1 receiver thread ended (pid=3300, tid=3463) Aug 31 09:12:09 vdr vdr: [3466] device 1 receiver thread started (pid=3300, tid=3466, prio=high) Aug 31 09:12:09 vdr vdr: [3309] SVDRP freetz < 127.0.0.1:35448 connection closed Aug 31 09:12:09 vdr vdr: [3309] SVDRP freetz < 127.0.0.1:35448 server destroyed Aug 31 09:12:09 vdr vdr: [3467] device 1 TS buffer thread started (pid=3300, tid=3467, prio=high) Aug 31 09:12:11 vdr vdr: [3300] retuning due to modification of channel 1127 (ProSieben HD) Aug 31 09:12:11 vdr vdr: [3300] switching to channel 1127 S19.2E-1-1017-61301 (ProSieben HD) Aug 31 09:12:11 vdr vdr: [3300] CAM 1: unassigned from device 1 Aug 31 09:12:11 vdr vdr: [3300] CAM 1: assigned to device 1 Aug 31 09:12:11 vdr vdr: [3467] device 1 TS buffer thread ended (pid=3300, tid=3467) Aug 31 09:12:11 vdr vdr: [3466] buffer stats: 100204 (0%) used Aug 31 09:12:11 vdr vdr: [3466] device 1 receiver thread ended (pid=3300, tid=3466) Aug 31 09:12:11 vdr vdr: [3468] device 1 receiver thread started (pid=3300, tid=3468, prio=high) Aug 31 09:12:11 vdr vdr: [3469] device 1 TS buffer thread started (pid=3300, tid=3469, prio=high)I cannot switch to a channel with "unsupported" caids:
CodeAug 31 09:14:08 vdr vdr: [3309] switching to channel 1101 S19.2E-1-1043-12522 (Eurosport 1 HD Austria) Aug 31 09:14:08 vdr vdr: [3309] CAM 1: unassigned from device 1 Aug 31 09:14:08 vdr vdr: [3309] SVDRP vdr < 127.0.0.1:52418 connection closed Aug 31 09:14:08 vdr vdr: [3309] SVDRP vdr < 127.0.0.1:52418 server destroyed Aug 31 09:14:08 vdr vdr: [3489] device 1 TS buffer thread ended (pid=3300, tid=3489) Aug 31 09:14:08 vdr vdr: [3488] buffer stats: 174276 (1%) used Aug 31 09:14:08 vdr vdr: [3488] device 1 receiver thread ended (pid=3300, tid=3488) Aug 31 09:14:08 vdr vdr: [3300] info: Kanal nicht verfügbar! -
With the latest delevopment git-Version there are now module parameters to control the cams:
Codeparm: caids0:CAIDs of emulated CAM0 (default empty = disabled) (array of hex) parm: caids1:CAIDs of emulated CAM1 (default empty = disabled) (array of hex) parm: sids0:ServiceIds of emulated CAM0 (default empty = all) (array of ushort) parm: sids1:ServiceIds of emulated CAM1 (default empty = all) (array of ushort)So, if your card can decrypt ORF1 and ProSieben HD you can use:
modprobe vtunerc caids0=0x098c sids0=4911,5301If you know that it can decrypt all with caid 0d98 then you can use:
modprobe vtunerc caids0=0xd98
The module parameter will change, cause now if you generate 4 adapters all associated cams get the same parameters.. -
Now i'm adding it to the satip program:
Where you can see it now in satip_vtuner.c line 249:
Code
Display MoreAug 29 16:10:33 [15442 satip_vtuner.c:241] debug: MSG_SET_PIDLIST: Aug 29 16:10:33 [15442 satip_vtuner.c:244] debug: 255 Aug 29 16:10:33 [15442 satip_vtuner.c:244] debug: 259 Aug 29 16:10:33 [15442 satip_vtuner.c:244] debug: 48 Aug 29 16:10:33 [15442 satip_vtuner.c:244] debug: 18 Aug 29 16:10:33 [15442 satip_vtuner.c:244] debug: 20 Aug 29 16:10:33 [15442 satip_vtuner.c:244] debug: 0 Aug 29 16:10:33 [15442 satip_vtuner.c:244] debug: 17 Aug 29 16:10:33 [15442 satip_vtuner.c:244] debug: 16 Aug 29 16:10:33 [15442 satip_vtuner.c:244] debug: 19 Aug 29 16:10:33 [15442 satip_vtuner.c:249] debug: got PMT: 96the_man Now it's your turn

-
That is why i said, sometimes it works, sometimes not.
I'm getting now the correct PMT from PAT "in first shot" with service-id which i receive over the CAM:
Code
Display More[vtunerc driver, version 2.0] vtunerc0 used by : 1 adapter0 in use : yes status : SIGNAL CARRIER VITERBI SYNC LOCK last change : 44 system : DVB-S2 modulation : PSK 8 frequency : 10832 symbolrate : 22000 fec : 2/3 rolloff : 0.35 pilot : auto scrambled : yes (PMT=96) pid tab : 96-PMT* 16-NIT* 17-SDT* 0-PAT* 20-TDT* 18-EIT* 48-FIL 259* 255-FIL* (len=9) ts data : 36900640 internal filler : 42864 external filler : 1316Last step now is to send the PMT to the satip program. I think i will add it to the pidlist as PID with high bits set to 1, e.g. 0xE060 for 96 (=0x60)
-
- Can we get this data from /vtuner-ng/satip/ code somehow? (like a global variable or in some struct, etc... )
Yes it should be possible.
I extended vtuner to detect encrypted channels and output this on /proc/vtunercX:
Code
Display More[vtunerc driver, version 2.0] vtunerc0 used by : 1 adapter0 in use : yes status : SIGNAL CARRIER VITERBI SYNC LOCK last change : 147 system : DVB-S2 modulation : PSK 8 frequency : 11464 symbolrate : 22000 fec : 2/3 rolloff : 0.35 pilot : auto scrambled : yes pid tab : 97-PMT* 16-NIT* 17-SDT* 0-PAT* 20-TDT* 18-EIT* 515* 511-FIL* (len=8) ts data : 836386432 internal filler : 1425040 external filler : 9212But i have still a "problem":
Code
Display More[17472.804701] vtunerc0: MSG_SET_FRONTEND, id=7 set signal NONE [17472.895166] vtunerc0: CAM: answer ca_pmt [17474.770261] vtunerc0: CAM: unassigned [17474.770267] vtunerc0: CAM: answer ca_pmt [17474.770280] vtunerc0: CAM: answer ca_pmt [17474.770284] vtunerc0: CAM: assigned [17474.770285] vtunerc0: CAM: got pid 1ff (511) [17474.770287] vtunerc0: CAM: answer ca_pmt [17475.048755] vtunerc0: got PMT for scrambled channel: 97 [17475.350408] vtunerc0: got PMT for scrambled channel: 98 [17475.976701] vtunerc0: got PMT for scrambled channel: 99 [17476.597434] vtunerc0: got PMT for scrambled channel: 100 [17477.212920] vtunerc0: got PMT for scrambled channel: 101 [17477.789343] vtunerc0: got PMT for scrambled channel: 102 [17478.144193] vtunerc0: got PMT for scrambled channel: 130 [17478.360099] vtunerc0: got PMT for scrambled channel: 131 [17478.570186] vtunerc0: got PMT for scrambled channel: 132 [17478.720634] vtunerc0: got PMT for scrambled channel: 133 [17478.842503] vtunerc0: got PMT for scrambled channel: 134I get several Pids with Table-ID 2, and the right one (here 97) is not always the first one.
Is there a "easy" way to check for the "right one"? -
If that is not allowed, let me know, i will remove it.
That is totally fine, keep it!
Your solution adds heavy processing of TS-data in satip. Do you retune after getting the PMT?
How do you get vdr thinking he can decramble those channels?
Vanilla vdr says "channel not available" if you try to change to channels without CAM.
My approach (https://github.com/joed74/vtuner-ng/tree/develop) is a "little bit" different:In the vtuner-ng kernel module i already process incoming packets and tag them:
Code
Display More[vtunerc driver, version 2.0] vtunerc0 used by : 1 adapter0 in use : yes status : SIGNAL CARRIER VITERBI SYNC LOCK last change : 9 system : DVB-S2 modulation : PSK 8 frequency : 11302 symbolrate : 22000 fec : 2/3 rolloff : 0.35 pilot : auto pid tab : 146 107-PMT* 16-NIT* 17-74s* 0-PAT* 20 18-EIT* 1922* 1921* 1920-FIL* (len=10) ts data : 24978808 internal filler : 301552 external filler : 2444So i already can get the PMT here. But i don't use it till now. It is just for information.
In the last week i implemented a CAM emulation over /dev/dvb/adapterX/caY
CodeAug 29 09:26:41 vdr vdr: [6348] CAM 1: module ready Aug 29 09:26:41 vdr vdr: [6348] CAM 1: vtuner-ng, 01, 0001, 0815 Aug 29 09:26:42 vdr vdr: [6348] CAM 1: system ids: 0D98 098C Aug 29 09:26:42 vdr vdr: [6348] CAM 1: replies to QUERY - multi channel decryption (MCD) possible Aug 29 09:26:42 vdr vdr: [6345] CAM 1: ready, master (vtuner-ng)So, if i change to ProSieben HD vdr just do so cause i emulate CAID 098C:
CodeAug 29 09:28:33 vdr vdr: [6353] switching to channel 1127 S19.2E-1-1017-61301 (ProSieben HD) Aug 29 09:28:33 vdr vdr: [6353] CAM 1: assigned to device 1 Aug 29 09:28:33 vdr vdr: [6385] device 1 receiver thread started (pid=6345, tid=6385, prio=high) Aug 29 09:28:33 vdr vdr: [6386] device 1 TS buffer thread started (pid=6345, tid=6386, prio=high) Aug 29 09:28:35 vdr vdr: [6345] retuning due to modification of channel 1127 (ProSieben HD) Aug 29 09:28:35 vdr vdr: [6345] switching to channel 1127 S19.2E-1-1017-61301 (ProSieben HD) Aug 29 09:28:35 vdr vdr: [6345] CAM 1: unassigned from device 1 Aug 29 09:28:35 vdr vdr: [6345] CAM 1: assigned to device 1Code
Display More[vtunerc driver, version 2.0] vtunerc0 used by : 1 adapter0 in use : yes status : SIGNAL CARRIER VITERBI SYNC LOCK last change : 145 system : DVB-S2 modulation : PSK 8 frequency : 11464 symbolrate : 22000 fec : 2/3 rolloff : 0.35 pilot : auto pid tab : 97-PMT* 16-NIT* 17-SDT* 0-PAT* 20-TDT* 18-EIT* 515* 511-FIL* (len=8) ts data : 128583540 internal filler : 743352 external filler : 9024With the information flow from VDR -> vtuner CA i get the information that now a encrypted channel will be seen - so i can send this informatione to the satip program as well
The only caveat is that vdr is not sending the PMT. So it can be necessary to use those information from my "pid tab"
Would be nice if you could test this as well in your environment... -
Also über ca_pmt des Cams wird in der Grundversion die der vdr spricht keine PMT-Pid gesendet.
Das ist wohl auch den Erfindern der CI-Schnittstelle aufgefallen, denn mit CI-Plus wurde das dann hinzugefügt:
The ca_pmt() APDU is extended also with the PMT_PID field, in order to save the CICAM the task of parsing the Local TS to obtain it.
Damit der VDR das an vtuner senden kann brauchts zusätzlich ein Plugin das ci.c erweitert

-