Posts by Joe_D

    the same problem with "develop" vtuner_proxyca.c 

    I'm using Ubuntu 22.04.5 and get no errors:

    Even with 13.1.0 no errors:

    Need to add the Channel switching log to see the place after what we expected to get a new PMT PID.

    In dmesg you will see output of vtunerc as well (outputs found pmt) and even you can cat /proc/vtunerc0 to see the actual state

    Why dont you setup with x_pmt=0?

    What's this??

    Code
    SETUP rtsp://192.168.0.22/?src=1&fe=1&freq=11464&pol=h&msys=dvbs2&mtype=8psk&sr=22000&fec=23&ro=0.35&plts=on&pids=none&x_pmt=96 RTSP/1.0
    RTSP/1.0 404 Not Found

    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 :rolleyes:
    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?? :S

    Ich könnte meine OctopusNet für weitere Tests zur Verfügung stellen. Hilft das was?

    Denke schon, musst dann aber auch vtuner aufsetzen...

    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 ORF1

    And i switch to Prosieben HD:

    I cannot switch to a channel with "unsupported" caids:

    Code
    Aug 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:

    Code
    parm:           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,5301

    If 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:

    Code
    [ 8157.094135] vtunerc0: MSG_PIDLIST r16s r17s r0s r20s r18s r48t r259t r255t 19s 96(PMT)

    Where you can see it now in satip_vtuner.c line 249:

    the_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:

    Last 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:

    But i have still a "problem":

    I 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:

    So 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

    Code
    Aug 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:

    Code
    Aug 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 1

    With 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 ||