[Patch] CAM-Tweaks für Multi Channel Decryption

  • The question is: what is one channel? To overcome the CAMs programm limit the sid-patch merges all pids of all programms into a single PMT and programm number. So in my case this "one channel" has up to 4 video pids and 8 audio/data pids.

    Helmut

    As i understand this workaround works only with ddci?


    BR,

    Yuri

  • das Update der inaktiven Pids mit "not_selected" findet gar nicht statt

    Das sollte man doch noch einbauen.

    Ich habe festgestellt dass ich bei einer laufenden Aufnahme zwar auf meine 3 anderen Programme Live umschalten kann, nach dem 4. mal bleibt de Bildschirm schwarz und es folgt ein emergency exit. Wenn ich dagegen die nicht mehr aktiven Pids mit "not_selected" auch in die PMT übernehme kann ich beliebig oft umschalten.

    Ich kann die am Abend diese verbesserte Version senden.

    Da bei deinem Test die 2 Programme aber nur hinzugefügt werden wird das noch nicht viel ändern.


    Was du vielleicht selbst herausfinden kannst ist, ob TS-Pakete mit den Pids von beiden Programmne beim "Host" landen.

    Wenn ich nicht falsch liege dann mit so etwas wie Peek13(tsPacket+1) in TsPostProcess() des Hosts.

    Helmut

  • Was du vielleicht selbst herausfinden kannst ist, ob TS-Pakete mit den Pids von beiden Programmne beim "Host" landen.

    Wenn ich nicht falsch liege dann mit so etwas wie Peek13(tsPacket+1) in TsPostProcess() des Hosts.

    Ok, das überfordert mich doch etwas. Ich bin schon froh, das ich dem Ganzen so halbwegs folgen kann. Da warte ich lieber auf den Patch oder Du sagst mir, was ich genau wo einbauen muss.


    In diesem Zusammenhang ist mir noch eingefallen, das ja auch das ddci2-plugin Debugging-Optionen hat. Ich habe das jetzt mal mitlaufen lassen und es gab da aus meiner Sicht keine Ungereimtheiten:

    Der Eine ist ein HD-Kanal, der Andere ein SD-Kanal. Wie man in der Zeiteinheit von 1min sieht, gehen tatsächlich in der Zeit, wo 2 Kanäle aktiv sind, eine Summe von Paketen beider Kanäle durch das Cam, es wird also erst einmal nichts geblockt.


    Wenn ich auf einen verschlüsselten Kanal schalte, gibt es am Anfang noch solche Meldungen, ein Bild ist aber trotzdem schon da und sie hören auch nach einer gewissen Zeit auf:


    kamel5

    VDR 2.4.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 29 Kernel 5.1 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    The post was edited 1 time, last by kamel5 ().

  • Bei den Logs von ddci2 habe ich das so gerechnet. Das sind zwar alles nur ca. Werte, die auch schwanken, kann aber durchaus passen:


    bezogen auf 1Min.

    1 Kanal HD: 1449186 - 1225169 ergibt ~ 224000

    1 Kanal SD: 214624 - 88678 ergibt ~ 126000

    2 Kanäle HD+SD: 825863 - 477308 ergibt ~ 349000


    Das ist durchaus plausibel.


    kamel5

    VDR 2.4.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 29 Kernel 5.1 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

  • Hier der Patch der inaktive Pids mit "not_selected" zur PMT hinzufügt.
    Als zweite Änderung wird nun der ca-desriptor nur mehr auf Programmebene aber nicht mehr bei den Pids hinzugefügt.
    Es ist mir zwar nicht klar ob es wirklich einen Unterschied macht, da es bei mir aber auch damit läuft ist es zumindest ein weiterer Versuch.


    Helmut

  • Mit dem letzten Patch wird es auch noch nicht hell:



    kamel5

    VDR 2.4.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 29 Kernel 5.1 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

  • HelmutB , with the latest vdr package update for yavdr (2.4.0-38yavdr0~bionic) I have problem using your vdr-2.4.0-camtweaks-1.patch.

    Without the patch vdr start up without problem, but without multi channel decryption. When I rebuild the deb package with the patch it gives problem with ddci driver included in the kernel I believe.

    The yavdr ansible vdr package 2.4.0-32yavdr0~bionic did not have these problems


    My setup:


    hts@vdrsrv01:~$ vdr -V

    vdr (2.4.0/2.4.0) - The Video Disk Recorder

    dbus2vdr (31) - control vdr via D-Bus

    ddci2 (1.0.5) - External Digital Devices CI-Adapter

    devstatus (0.4.1) - Status of dvb devices

    live (2.3.1) - Live Interactive VDR Environment

    markad (0.1.6) - Mark advertisements

    satip (2.4.0) - SAT>IP Devices

    softhddevice (0.7.0) - A software and GPU emulated HD device

    streamdev-server (0.6.1-git) - VDR Streaming Server


    - updated ddci2 drivers from ppa:jasmin-jessich/media-build-dkms


    - Yavdr ansible vdr package from https://launchpad.net/~yavdr/+…xperimental-vdr/+packages .

    The deb package version which do not work is vdr - 2.4.0-38yavdr0~bionic.

    I have tried to removing these patches included after the update and rebuilding the deb package, but it do not help.

    vdr-2.4.0-30-fix-ci-sendanswer.diff

    vdr-2.4.0-31-fix-invalid-lock-sequence.diff

    vdr-2.4.0-32-fix-remote-timers-lstt-550.diff

    vdr-2.4.0-33-fix-compiler-warning-add-attr-packed.diff

    vdr-2.4.0-34-fix-repeat-kbd.diff


    Thanks

    Harald

  • Did you rebuild the satip-plugin too ?


    I will build my VDR with all official patches and check it.

    Helmut


    Edit:

    VDR with all patches up to #34 and camtweaks-1.patch works normal for me.

    But - as i enabled VDR's patchlevel checking - i have to rebuild all plugins.

  • Quote

    Did you rebuild the satip-plugin too ?

    Yes, i rebuild the satip and the ddci2 plugin.

    When I remove the ddci2 plugin vdr starts normal with vdr package 2.4.0-38yavdr0~bionic.

    I will try to reinstall the server with yavdr again to see if it helps.


    Do you know if I need the updated ddci2 drivers from ppa:jasmin-jessich/media-build-dkms. The kernel version I use now is Linux vdrsrv01 4.15.0-50-generic .


    Thanks for the help.


    Harald

  • Do you know if I need the updated ddci2 drivers from ppa:jasmin-jessich/media-build-dkms.

    Sorry, i don't know.

    To find out if it is the patch or the rebuild-process iitself which causes the kernel-crash, try to rebuild the VDR deb-package and satip + ddci2 - but without the camtweaks-patch applied.

    Helmut

  • I reinstalled the server and now it works as expected. The only think i dropped when I setup my server was updated ddci2 drivers from the ppa:jasmin-jessich/media-build-dkms repository.

    I do not know why the kernel crash was happing, but I must have done something with my server before this trouble.


    Thank you for the help, again.


    Harald

  • Gents, is this error somehow related to this patch? I get the error every week or so ...


  • Hum, not sure. I think perhaps something happens in Chrome... the logs are English when I paste them but Chrome is trying to help me with the German part of the forum (of which I only have very basic knowledge!).


    Does this work?



    If not see here: https://pastebin.com/tTMsiYQ3

  • You start a recording at 14.58:00 and 30 seconds later VDR initiates the emergency exit. That means usually that the TS-stream for the recording is not decrypted.

    Code
    1. May 19 14:58:00 timeshift changeover: [1747] writes hours id '22 @timeshift 'to /srv/vdr/video/Tid_for_hage_(R)/2019-05-19.14.58.5-0.rec/.timer
    2. May 19 14:58:00 timeshift vdr: [8624] recording thread started (pid = 1747, time = 8624, prio = high)
    3. May 19 14:58:00 timeshift CEO: [1769] VNSI: Ask for clients to reload timers
    4. May 19 14:58:01 time shift VDR: [8622] CAT: 09 0A 0B 00 89 F3 80 04 34 10 EE 54 07 93 05 3C FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
    5. ...
    6. May 19 14:58:31 timeshift vdr: [8624] ERROR: video data stream destroyed
    7. May 19 14:58:31 timeshift changeover: [8624] initiates emergency exit

    The interesting thing is the CAT-dump. In April you sent me this log:

    Code
    1. Apr 1 19:10:18 timeshift vdr: [17502] CAT: 09 0A 0B 00 F3 89 80 04 34 10 EE 54 07 93 05 3C FF FF ...
    2. 0x09 -> marker
    3. 0x0A -> len
    4. 0x0B00 -> caid
    5. (0xF389 & 0x1FFF) = 0x1389 -> your emm-pid
    6. 80 04 34 10 EE 54 -> private data
    7. 07 93 05 3C -> crc32

    Now the 2 bytes for the CAT-PID are reversed, but the CRC32 is unchanged:

    Code
    1. May 19 14:58:01 time shift VDR: [8622] CAT: 09 0A 0B 00 89 F3 80 04 34 10 EE 54 07 93 05 3C FF FF ...
    2. 0x09 -> marker
    3. 0x0A -> len
    4. 0x0B00 -> caid
    5. (0x89F3 & 0x1FFF) = 0x9F3 -> your emm-pid ---> bytes reversed !!!!!
    6. 80 04 34 10 EE 54 -> private data
    7. 07 93 05 3C -> crc32 ---> the same as in April, means wrong CRC32 (or that one in April)

    And so i think your provider sent wrong data and without EMMs your CAM does not decrypt at all.

    Do you have more CAT-dumps from today?


    Helmut

  • Ok here are some more logs: