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

    Zitat von HelmutB

    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

    Zitat von Yuri666

    works only with ddci?

    I use ddci2 for the WInTV-CI, but the patch has nothing to do with it and should work with any CI.

    With this method the only (programm) limit is the number of pids which the CAM can actually hold. And the length of the PMT message.

    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Zitat von HelmutB

    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

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Zitat von HelmutB

    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.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Einmal editiert, zuletzt von 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.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    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.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    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.

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Einmal editiert, zuletzt von HelmutB ()

    Zitat

    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

    Zitat von haraldov

    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

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    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
    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
May 19 14:58:00 timeshift vdr: [8624] recording thread started (pid = 1747, time = 8624, prio = high)
May 19 14:58:00 timeshift CEO: [1769] VNSI: Ask for clients to reload timers
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
...
May 19 14:58:31 timeshift vdr: [8624] ERROR: video data stream destroyed
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
    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 ...

0x09 -> marker
0x0A -> len
0x0B00 -> caid
(0xF389 & 0x1FFF) = 0x1389 -> your emm-pid
80 04 34 10 EE 54 -> private data
07 93 05 3C -> crc32

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

    Code
    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 ...

0x09 -> marker
0x0A -> len
0x0B00 -> caid
(0x89F3 & 0x1FFF) = 0x9F3 -> your emm-pid --->  bytes reversed !!!!!
80 04 34 10 EE 54 -> private data
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

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Ok here are some more logs:


Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden