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

  • So all with 09 0A 0B 00 F3 89

    and today 09 0A 0B 00 89 F3 with the last 2 bytes reversed.

    Can you find more of this wrong CAT-PIDS by greping for '89 f3' in your logs?


    A workaround could be to look for this wrong PID in ci.c / cCaPidReveiver::Receive() and adjust it - but this is more a hack then a fix.

    Helmut


    Edit: corvy - you can try this patch. It compiles, but is completly untested

  • I think I thought too complicated last night.

    It's better to treat it what it is - a plain data error. And data with faulty CRC32 checksum should be simply ignored.

    Here is a more general patch fo this problem (and it has nothing to do with your provider - so ignore the patch in post #61).


    Helmut

  • will this be proposed for the next release in case it is stable?

    I dont know, maybe only if this patch really solves your problem.


    If you can catch the CRC-error ( look for cCaPidReceiver::Receive() : CRC-ERROR - skip invalid CAT section [Ver.... with a following cCaPidReceiver::Receive() : got valid CAT section [Ver....in your logs ) then i think the chances are good.


    Helmut

  • Seems I have too many patches so this last one fails to apply:



    Attached my ci.c file (had to zip it due to forum not accepting .c extension upload). I have patched most of kls patches (up to 26).


  • Your manually patch looks OK. I applied it with all vdr-patches up to #34 but didn't think of your HEXDUMP() line.


    I think it will take some time to catch the data/crc error because the CAT is first evaluated on a channel-switch, but after that only if the catversionchanges - but i don't know how often this happens (hours ?, days?).
    And so i think, for test purposes, it would be better to modify the patch and verify the checksum of all CATPID occurences, regardless of catversion.

    I will try this tonight - and open a new thread for it because it has nothing to do with MCD or MTD.


    Helmut

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

    Weil ich nicht bemerkt habe, das die ECM-Pids immer nur auf Programm-Ebene in die caPMT eingetragen und damit auf alle EsPids angewendet wurden. Mein Test mit 4 Programmen war nur deshalb erfolgreich, weil sie alle die gleiche ECM-Pid verwenden (shared Pids).

    Hier nun ein Patch, der die zur EsPid passende ECM-Pid auf Stream-Ebene in die caPMT einträgt. Läuft so bei mir nun auch mit mehreren Programmen und unterschiedlichen ECM-Pids.

    kamel5 : der Plugin-Patch ist nicht erforderlich, die Debug-Ausgaben sind in diesem Patch enthalten


    Helmut

  • Hier eine neue Version des CamTweak Patch, die es ermöglicht, das Programm Limit von Ca-Modulen anzuheben.
    Dazu wird nicht wie sonst üblich für jedes Programm eine eigene CA_PMT an das CAM übertragen, sondern alle Programme (Stream- und ECM-Pids) eines CamSlot bzw. bei MTD auch aller MtdCamslots in eine einzelne CA_PMT gepackt.

    Das Programm Limit hängt dann nur von der möglichen Anzahl der Pids ab, die das CAM aufnehmen kann.


    Es gibt dazu 2 neue Optionen in der camtweaks.conf, die beste und einfachste wäre der Wert 0x21 (MTD) onder 0x25 (nur MCD).

    Code: camtweaks.conf
    1. # CAMTWEAK_PACK_MCD 0x10 - pack each CamSlot into a single CA_PMT - for CAMs with limited program slots
    2. # CAMTWEAK_PACK_MTD 0x20 - pack *all* MtdCamSlots into a single CA_PMT - for CAMs with only one program slot
    3. # Example: 0x21,0,<...> tweaks enabled, PACK_MTD (single CA_PMT for MCD+MTD, implicit MCD and unlimited number of programs)

    Ich kann nun mit dem SimpiTv-Modul statt 2 nun auch 7 Programme gleichzeitig entschlüsseln.

    Jun 24 23:48:27 gentoo64vdr vdr[2942]: [2942] SendCaPmts(MTD) CAM 1: [0] actives in CAM: 7 -> 7 (20 pids)


    Es funktioniert grundsätzlcih auch mit der Sky CAM - allerdings mit ein paar Einschränkungen wie sich bei den Tests von kamel5 herausgestellt hat.

    - Maximal 2 Programme gleichzeitig - vermutlich eine Beschränkung auf 6 Stream-Pids

    - MTD it derzeit noch nicht möglich - nicht einmal die Simulation mit KEEPPIDS in mtd.c

    - Beim Hin- und Herzappen auf andere Kanäle während einer laufenden Aufnahme kömmt irgendwann der Punkt wo der 2. Kanal nicht mehr

    entschlüsselt wird (das passiert manschmal schon nach 8 oder auch erst nach 50 mal), Es ist aber noch nicht klar warum das so ist und ob es nur bei der SKY CAM Auftritt.


    Wenn jemand den Patch testen möchte - ein paar Erfahrungsberichte wären sehr interessant.


    Helmut

  • Ich habe mich letztes Wochenende zu sehr auf dieses packen der CA_PMT konzentriert, dass ich, nach einer letzten kleinen Änderung, den "Normal" Modul nicht aufmerksam getestet habe. Daher ist mir auch nicht aufgefallen, des er mit dem obigen Patch nicht mehr richtig funktioniert.

    Auch beim mitzählen der aktven Programme war noch ein Fehler.

    Hier nun ein Update in dem diese Fehler behoben sind.


    Zusätzlich habe ich noch eine kleine Ergänzung beim Entfernen von Pids eingefügt, da ich auch Pobleme nach mehrmaligem Umschalten bei einer laufenden Aufnahme festgestellt habe. Nun werden die aktuell zu entfernenden Pids einmalig mit "NOT_SELECTED" in die CA_PMT aufgenommen. Das hat bei mir geholfen - ist aber vielleicht auch CAM-abhängig.

    kamel5 - ist in etwa wie im der sid9.patch - ich hoffe, es gibt keine Verschlechterung bei dir.


    Helmut

  • Hello HelmutB I have just now upgraded to vdr-2.4.1 and this new patch. In my log I get the following error:



    Should I worry about this? Just remove this from setup.conf?


    It also seems I cannot get multichannel decrypt:


    Code
    1. Aug 5 14:30:50 timeshift vdr: [23752] VNSI: Welcome client 'XBMC Media Center' with protocol version '13'
    2. Aug 5 14:30:51 timeshift vdr: [23744] CAM 1: module ready
    3. Aug 5 14:30:51 timeshift vdr: [23746] CAM 2: no module present
    4. Aug 5 14:30:53 timeshift vdr: [23744] CAM 1: Conax Conditional Access, 01, CAFE, BABE
    5. Aug 5 14:30:58 timeshift vdr: [23744] CAM 1: system ids: 0B00
    6. Aug 5 14:31:01 timeshift vdr: [23744] CAM 1: doesn't reply to QUERY - only a single channel can be decrypted
    7. Aug 5 14:31:01 timeshift vdr: [23725] CAM 1: ready, master (Conax Conditional Access)
    8. Aug 5 14:31:01 timeshift vdr: [23725] CAM 2: ready, master (empty)
    9. Aug 5 14:31:01 timeshift vdr: [23725] switching to channel 1 C-70-9-101 (NRK1 Østlandssendingen)
    10. Aug 5 14:31:01 timeshift vdr: [23756] SVDRP server handler thread started (pid=23725, tid=23756, prio=low)


    Second part is this:


    camtweaks.conf:


    I also have the DDCI2 and VNSISERVER plugins compiled and enabled. :)

  • Hello again HelmutB . Not sure how I fixed it but I went into the GUI setup, enabled CA tweaks under miscellaneous. First time I enabled it and exited it did not stick, but second time I enabled and then chose restart from the GUI and then it worked. Now Camtweaks works again. The others error remains but the WAF is back on-track :)

  • Hi Corvy !

    First, the camtweaks-2.1.patch is faulty, Sorry, but I spent the the last weeks to make the Sky CI+ CAM working, so i did not post a better Version.

    But today i got a possitive feedback and so i will post a new camtweaks2.2.patch in the next hour or so.


    And yes, you can delete EnableCaModuleTweaksin setup.conf (if you stay on version2), i did a reneming and forgot to think on the old name in camtweaks1. And that why you had to enable camtweaks again in setup.


    BR

    Helmut


    BTW: the description in your camtweaks.conf should look a little different in version 2 , as there are 2 more possible options to set.

    And if you have troubles, the camtweaks1.patch should stil work with vdr-2.4.1

  • Nachdem der camtweaks-2.1 Patch bei den neuen Funktione immer noch fehlerhaft war, hier nun mit etwas Verzögerung der camtweaks-2.2.patch.


    Wie es aussieht lassen sich damit nun auch mit der Sky-CAM 2 Programme gleichzeitig aufnehmen.

    Für MTD und CI+ ist (unter anderem) auch noch der vdr-2.4.1-Mtd-LockedTsPostProcess.patch von hier erforderlich.

    Und damit das CAM bei SIngle-und MCD sowie MTD immer gleich behandelt wird, kann auch noch vdr-2.4.1-Mtd-StopDecrypting.patch von hier eingespielt werden.


    Die Einstellung 0x3 sollte unverändert wie in camtweaks-1 funktionieren.

    Mit der Option 0x23 werden alle aktiven Progrmme (auch bei MTD) in einer einzigen CA_PMT an das CAM gesendet ( mit 0x13 eine CA_PMT je Transponder ). Das funktioniert bei einigen CAMs problemlos, bei einer meiner CAMs habe ich allerdings Bildstörungen beim Entfernen von Pids festgestellt. Der Erfolg kann also etwas vom Modul abhängen.


    Helmut

  • Hier das Update auf camtweaks-2.3 mit ein paar Vereinfachungen und Verbesserungen.


    - nach dem Übertagen einer CA_PMT an das Modul und vor dem Senden der nächsten TPDU werden nun mind. 300ms abgewartet.

    Das löst das Problem, bei dem ein Programmwechsel nach mehrern Umschaltungen irgendwann nicht mehr möglich war.


    - Mit MTD können bei einem Programmwechsel alte TS-Pakete die noch im CI-Treiber waren nicht mehr auf die Original-Pid zurückgemappt

    werden und bekommen mit 0x1FFF die Pid eines TS-NULL Pakets. Das führte manchmal zu einer 3 Sekunden Verzögerung so wie hier:

    Code
    1. Jul 20 13:59:21 home-05.home.de vdr[1753]: [1753] CAM 1: unassigned from device 1
    2. Jul 20 13:59:21 home-05.home.de vdr[1753]: [1753] CAM 1/1: reusing MTD CAM slot
    3. Jul 20 13:59:21 home-05.home.de vdr[1753]: [1753] CAM 1/1: MTD mapper cleared
    4. Jul 20 13:59:21 home-05.home.de vdr[1753]: [5813] cCamSlot::TsPostProcess: Pid #0: 8191 (1FFF) S P : 9BFF1F47 ...
    5. Jul 20 13:59:24 home-05.home.de vdr[1753]: [1753] CAM 1: assigned to device 1

    Zumindest in der Kombination ddci2+ddbridge können das auch einige hundert Pakete sein, daher werden diese nicht mehr an das Device weitergegeben.


    - Die Programm Limits werden nun schon vor einer möglichen Zuordnung eines Device an den CamSlot überprüft.
    - Die Debugmeldungen werden nun nicht mehr ausgegeben sondern können mit 0x1000 (CAMTWEAKS) und 0x2000 (DEBUG_MTD) dazugeschalten werden


    Zusätzlich sollten (weiterhin) auch noch der vdr-2-4-1-mtd-lockedtctspostprocess-patch sowie der vdr-2-4-1-mtd-stopdecrypting-patch angewendet werden.


    Helmut

  • Hier noch einige Hinweise für die Sky-Pairing Opfer, die bisher mit dem A****crypt glücklich waren und nun mit dem SKY-ci-minus CAM arbeiten müssen.

    Mit dem Patch aus dem vorherigen Post ist es jetzt möglich 2 Kanäle gleichzeitig zu empfangen. Das klingt zwar erst einmal nicht viel, ist aber 100% mehr als vorher ging. Ab dem 3. Kanal bleibt das Bild einfach schwarz.


    Um das SKY-CAM effektiv zu nutzen, muss erstens der Patch aktiviert (Menü->Einstellungen->Sonstiges->Enable CA module tweaks) und in der camtweaks.conf folgender Eintrag gemacht werden:


    0x23,2,<CAFE:BABE,Sky NDS CI Plus Modul


    Änderungen in der camtweaks.conf nur bei gestoppten VDR vornehmen.

    Damit ist es dann möglich, aus allen abonnierten SKY Kanälen 2 Kanäle, auch von unterschiedlichen Transpondern, gleichzeitig zu entschlüsseln.


    Bei den Tests hat sich gezeigt, das es momentan noch eine Einschränkung gibt. Man sollte während einer laufenden Aufnahme auf dem ersten Kanal nicht, wie bisher vielleicht gewohnt, auf dem zweiten Kanal oft "Zappen". Es treten dann nach einer unbestimmten Anzahl von Umschaltungen, im Schnitt so zwischen 10 und 30, Bildstörungen in der Aufnahme vom ersten Kanal auf. Die Störungen sind auch nicht regelmäßig, treten aber immer wieder bei Umschaltungen auf.

    Die genaue Ursache dafür konnte bisher nicht geklärt werden, möglicherweise liegt das auch am CAM selbst.


    Insgesamt funktioniert das Ganze aber schon recht gut, 2 gleichzeitige Aufnahmen sind unproblematisch und eine Aufnahme mit gleichzeitigem Live-TV auf einem anderen Kanal auch.


    Grüsse

    kamel5

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