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

  • Ich hab es gerade ausprobiert - es wird (leider) doch "UPDATE" verwendet, es fehlt nur die Anpassung an !activePmtsCamin der dsyslog() Zeile darüber. Und bei mir geht es auch mit dieser Änderung.

    Gibt es bei 2 Programmen einen "Data stream broken" Fehler wenn du >60 Sekunden wartest oder bleibt das Bild einfach schwarz (und stumm) ?

    Helmut

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

  • Gibt es bei 2 Programmen einen "Data stream broken" Fehler wenn du >60 Sekunden wartest oder bleibt das Bild einfach schwarz (und stumm) ?

    Das hängt davon ab, was ich zuerst mache.

    Wenn ich zuerst eine Aufnahme starte und dann Live auf den 2.Kanal umschalte, bleibt das Bild einfach schwarz, die Aufnahme läuft korrekt weiter.

    Wenn ich Live auf dem 1.Kanal schaue und dann eine Aufnahme auf dem 2.Kanal starte, gibt es "Data stream broken" Fehler und keine Aufnahme.


    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ist denn das DVB-T2 SimpliTV-Modul auch ein CI+ Modul? Denn bei CI+ laufen doch so ein paar Sachen anders.

    Z.B. wird der TS-Stream ja nach der Entschlüsselung vom Modul wieder verschlüsselt um dann letztendlich von VDR-Plugin wieder entschlüsselt zu werden. Keine Ahnung, ob das überhaupt so mit mehreren Streams funktioniert.


    Jedenfalls gibt es den Multistream-Support bei CI+ erst ab der CI+ Version 1.4 und da auch nur optional.

    Und weder das Sky-Modul noch das VDR-Plugin beherrschen den CI+ 1.4 Standard

  • nanohcv : Ja, es ist ein CI+ Modul, aber CI+ wird nur von ein paar Privaten verwendet. Ich brauche es aber nicht und kenne mich damit auch nicht wirklich aus. Und vermutlich sind die Versuche für das Sky-Modul tatsächlich vergebens, für "normale" Programme kann es schon Vorteile haben.

    Das hängt davon ab, was ich zuerst mache.

    Auch seltsam. "Data stream broken" kenne ich wenn die Daten unverschlüsselt zum VDR kommen.

    Wenn man die CI+ Besonderheiten einmal ausblendet fällt mir nur noch ein, dass es möglicherweise zum Programm-Limit auch ein Pid-Limit gibt (3 Pids?)


    Hier ein Patch (die "UPDATE" Variante) um das zu testen. Sid-4 verwendet nur den Video-pid eines Programms. Vielleicht kannst du damit 2 oder 3 Stummfilme sehen.

    Helmut

  • Auch seltsam. "Data stream broken" kenne ich wenn die Daten unverschlüsselt zum VDR kommen.


    Wenn man die CI+ Besonderheiten einmal ausblendet fällt mir nur noch ein, dass es möglicherweise zum Programm-Limit auch ein Pid-Limit gibt (3 Pids?)

    "Data stream broken" bedeutet eigentlich nur, das der vdr keine verwertbaren Daten zum Aufnehmen hat.


    Ich habe jetzt den letzten Patch nochmal probiert und es ist genau so wie vorher. Also ein Pid-Limit scheint hier auch nicht zu wirken.

    Mit den Stummfilmen wird es also auch nichts. :) Das Bild vom 2.Programm bleibt weiterhin schwarz.:(


    Grüsse

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Für dein Modul haben wir wie es Aussieht derzeit das Ende der Fahnenstange erreicht.

    Vielleicht liegt es doch am mappen der Sid. Das eine Programm das du sehen kann hat ja eine RealSid von 131, MY_SID ist auch 131 - bleibt also gleich, Aber auch wenn es nicht so wäre sind mir im Moment leider die guten Ideen ausgegangen.

    Aber vielleicht ergibt sich noch etwas.

    Helmut

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

  • Jetzt habe ich kurz in der CI Plus Specification 1.3.1 nachgelesen.

    Bei CI+ gibt es die sogenannnte URI (Usage Rules Information) die mit der (echten) Programmnummer in Verbindung steht.


    Das kann auch einer der Gründe sein, warum es nach nach dem Mappen der Sid durch MTD oder den sid-patch von hier finster bleibt.

    Helmut

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

    Einmal editiert, zuletzt von HelmutB ()

  • Für dein Modul haben wir wie es Aussieht derzeit das Ende der Fahnenstange erreicht.


    Vielleicht liegt es doch am mappen der Sid. Das eine Programm das du sehen kann hat ja eine RealSid von 131, MY_SID ist auch 131 - bleibt also gleich, Aber auch wenn es nicht so wäre sind mir im Moment leider die guten Ideen ausgegangen.

    Bei CI+ gibt es die sogenannnte URI (Usage Rules Information) die mit der (echten) Programmnummer in Verbindung steht.


    Ich befürchte ja auch, das es hier keine Lösung gibt.

    Allerdings glaube ich nicht, das es an der SID liegt, den ich bekomme ja den alternativen Sender alleine hell, trotz falscher SID.

    Eine letzte Idee hätte ich aber noch:

    Wie hier zu sehen ist, wird ja immer versucht, zu den bereits vorhandenen Pid welche hinzuzufügen.

    Möglicherweise lässt sich ja auch die Anzahl der Pid nachträglich nicht mehr ändern, d.h. es müssen alle Pid erst einmal gelöscht und dann von 0 an neu hinzugefügt werden.


    Vielleicht fällt Dir dazu noch was ein.


    Nachtrag:

    Ich habe es gerade noch mal mit einer ganz anderen Sid versucht und selbst da wird es hell, allerdings erst nach Eingabe der Jugenschutz-Pin.

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Einmal editiert, zuletzt von kamel5 ()

  • mit einer ganz anderen Sid versucht und selbst da wird es hell,

    Ich war mir nicht sicher ob es nicht mit der echten Sid 131 zusammenhängt - scheint aber doch nicht so zu sein.

    MY_SID ist 2x definiert - InjectEit verwendet immer noch 131 - deshalb der Jugendschutz.

    Der "beste" Patch ist übrigens die Version 4 wenn du in Zeile 85 + return; entfernst. Und das 2. MY_SID ist in Zeile 97.


    Bei Mai 03 12:32:32 vdr[12554]: [12554] BuildCaPmts CAM 1: Pid 1279 (4FF) -wird die PID an das CAM gemeldet, ist aber nicht aktiv ("not_selected") und könnte auch mit einer anderen Pid überschrieben werden.

    Mit Mai 03 12:32:32 vdr[12554]: [12554] BuildCaPmts CAM 1: Pid 1279 (4FF) + wird das Attribut auf "ok_descrambling" geändert. Um den "Platz" deser Pid wieder für andere freizumachen muß das Attribut zuerst mit einem Update wieder auf "not_selected" geändert werden. Der erste Eintrag stört oder blockiert daher nichts und wird eher nur aus "programmtechnischen" Gründen gesendet.


    Zur URI: Ich vermute dass das Entschlüsseln auf CA-Ebene sogar durchgeführt wird, danach werden die Pakete wieder "verpackt" und an den Host (=plugin) gesendet. Auch wenn bis hierher alles zusamenpassen würde - wenn der Host sich an die Vorgaben der URI hält, dann darf er gar nicht mehr tun. Das ist jetzt aber nur geraten.


    Helmut

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

  • Ich war mir nicht sicher ob es nicht mit der echten Sid 131 zusammenhängt - scheint aber doch nicht so zu sein.

    MY_SID ist 2x definiert - InjectEit verwendet immer noch 131 - deshalb der Jugendschutz.


    Der "beste" Patch ist übrigens die Version 4 wenn du in Zeile 85 + return; entfernst. Und das 2. MY_SID ist in Zeile 97.

    Ok, habe ich mal gemacht und funktioniert auch ohne Pin-Abfrage.

    Bei Mai 03 12:32:32 vdr[12554]: [12554] BuildCaPmts CAM 1: Pid 1279 (4FF) -wird die PID an das CAM gemeldet, ist aber nicht aktiv ("not_selected") und könnte auch mit einer anderen Pid überschrieben werden.

    Mit Mai 03 12:32:32 vdr[12554]: [12554] BuildCaPmts CAM 1: Pid 1279 (4FF) + wird das Attribut auf "ok_descrambling" geändert. Um den "Platz" deser Pid wieder für andere freizumachen muß das Attribut zuerst mit einem Update wieder auf "not_selected" geändert werden. Der erste Eintrag stört oder blockiert daher nichts und wird eher nur aus "programmtechnischen" Gründen gesendet.

    Ok, könnte man dann z.B. folgendes zum Testen machen:

    Man hat ja pro Kanal 3 Pid, wenn man also 2 Kanäle betrachtet 6 Pid. Wenn also bereits am Anfang 6 Pid inaktiv an das CAM gemeldet werden und dann jeweils 3 pro Kanal überschrieben werden. Könnte so etwas klappen?


    Zur URI: Ich vermute dass das Entschlüsseln auf CA-Ebene sogar durchgeführt wird, danach werden die Pakete wieder "verpackt" und an den Host (=plugin) gesendet. Auch wenn bis hierher alles zusamenpassen würde - wenn der Host sich an die Vorgaben der URI hält, dann darf er gar nicht mehr tun. Das ist jetzt aber nur geraten.

    Das ist zwar auch nicht ausgeschlossen, daran glaube ich aber eigentlich nicht. Denn das *** Plugin, über das wir hier nicht reden, soll dem CI ja nur vorspielen, das es auf eine CI+ Hardware trifft.


    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Hi Helmut,

    current implementation ci+ in vdr ignore uri value. But for compliance ci+ specs uri should be pass from CAM to host to every channel swithing. And host should to answer. Every new uri pass to CAM from air by emm or ecm (not speceifed in ci+ specs). Maybe in your case you didn't pass to CAM necessary pids to transfer uri to CAM and so on to host.

    BR,

    Yuri

  • Wenn also bereits am Anfang 6 Pid inaktiv an das CAM gemeldet werden...

    Man muss keinen Plätz für die Pids reservieren. Solange die CAM freien Programm- und Pid Speicherplatz hat, werden sie in die Pid-Liste der CAM übernommen. Um diese Belegung wieder aufzuheben müssen sie entweder mit "not_selected" wieder freigegeben oder die ganze Programm- und Pid-Liste mit CPLM_ONLY oder CPLM_FIRST gelöscht werden.

    Das wIrd also nicht nicht viel ändern.


    Kann man mit deiner CAM auch Programme empfangen die nicht mit CI+ verschlüsselt sind ? Eine naive Frage, oder :-).


    Yuri666 : if the CAM needs additional or special pids then this will never happen because VDR does not care about CI+.


    Helmut

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

  • Kann man mit deiner CAM auch Programme empfangen die nicht mit CI+ verschlüsselt sind ? Eine naive Frage, oder :-).

    Naja, das CI+ hat an sich nichts mit der Programmverschlüsselung zu tun. Das betrifft nur die Schnittstelle zwischen CAM und Gerät+++, halt eingeführt, um die Nutzer stärker zu gängeln.

    Man konnte die Sky-Smartcard in der Vergangenheit auch in einem normalen Cam (ohne +), das war das Alpha**, benutzen, das konnte MTD. Da das mit den gepairten Smartcards jetzt nicht mehr geht, die gehen nur noch mit dem Sky-Cam, und das hat CI+, halt der Versuch, ob damit mehr als ein Programm gleichzeitig hell zu bekommen ist. Wenn man die Smartcard mit einem normalen Cam verheiraten könnte, was natürlich nicht gewollt ist, würden auch damit die Programme hell werden.

    Da bleibt dann wahrscheinlich nur noch die Hoffnung, das es vielleicht für das Alpha*** doch noch irgendwann mal ein Update gibt, mit dem es wieder hell wird.


    Auf jeden Fall möchte ich mich schon mal für Deine Mühen bedanken, auch wenn bisher nur herausgekommen ist, das es nicht geht.


    Grüsse

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • if the CAM needs additional or special pids then this will never happen because VDR does not care about CI+.

    I don't use vdr now, but other software transfer uri successfully and fast in dvb card with embedded CI and very slow and partially in ddci hardware. So i think needs to care about additional pids in this case. (I don't know about what of pids...)


    BR,

    Yuri

  • Hi Yuri,


    the problem here isn't that it doesn't work at all with ci+, but it works only with one channel in parallel, not with multiple channels.


    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Neotion ci+ CAMs usually can open only one channel. It firmware restriction.

    Thanks for this bad info. We made some tests, but with this info I think we have to live with that.


    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Naja, das CI+ hat an sich nichts mit der Programmverschlüsselung zu tun.

    Das war eben die Frage - gibt es auch Sender sie die CI+ Erweiterung nicht nutzen. Bei SimpliTV gibt es (gegen Aufpreis) 40 oder mehr Programme, aber nur eine Handvoll davon verwendet CI+, der Rest verschlüsselt ohne +.

    auch wenn bisher nur herausgekommen ist, das es nicht geht.

    Naja, für mich ist schon etwas herausgekommen - mind. 4 statt 2 Programme gleichzeitig. Werde ich zwar niemals brauchen, aber ich könnte wenn ich wollte :-).


    Eines ist doch aufgefallen: das Update der inaktiven Pids mit "not_selected" findet gar nicht statt - es werden nur die aktiven Pids übertragen. Ich werde dem noch nachgehen, vielleicht ergibt sich eine neuer Test.

    Helmut

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

  • Das war eben die Frage - gibt es auch Sender sie die CI+ Erweiterung nicht nutzen.

    Ok, da hatte ich das falsch verstanden. Ich habe ja das CAM im Fernseher probiert, auf verschiedenen Sendern, und dabei ist mir nicht aufgefallen, das sich einer anders verhalten hätte.


    vielleicht ergibt sich eine neuer Test.

    Ich würde mich freuen, immer her damit.


    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Neotion ci+ CAMs usually can open only one channel.

    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

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

Jetzt mitmachen!

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