Beiträge von HelmutB

    Auf meinem Notebook ohne Hardwarebeschleunigung mit xineliboutput:


    Last ohne Fortschrittsanzeige 30-35%


    Erhöhung mit Fortschrittsanzeige:

    VDR-2.3.9 --> +2%

    1. Patch --> +20%

    2. Patch --> +10%

    Helmut

    Um die CA_PMT Sache wirklich zu verstehen, habe ich heute meine 3 CAMs mit verschiedenen Queries abgefragt und folgendes beobachtet:

    Die beiden CAMS vom SMIT antworten überhaupt nicht.

    Die NEOTION CAM antwortet bei CPLM_ONLY Queries positiv mit "possible", bei CPLM_ADD nur beim ersten Query positiv, beim zweiten ADD gar nicht und ab dem dritten ADD negativ mit "no entitlement". Der Schönheitsfehler bei "possible" ist, das es auch ohne eingelegter Smartcard oder bei eigentlich gar nicht unterstützer CAIDs gemeldet wird und daher auch falsch sein kann.


    Ich habe leider keine Lösung für dieses Query Problem, da aber alle 3 CAMs definitv zumindens 2 Programme gleichzeitig entschlüsseln können werde ich vorläufig den Hack von Klaus aus dem 2. Post beibehalten.


    Helmut

    Hi and thank you both for your input.


    this is not direct releated to the issue but may help to debug
    https://jokersys.com/2018/03/0…rface-ci-descrambling-tv/

    Not directly this page, but the source code here https://github.com/aospan/libj…aster/src/joker_en50221.c

    and the function joker_en50221_sync_cam(struct joker_t * joker) gave me an idea on how to use CA_PMT(query) correctly.


    The point is that a query (usualy) can only be applied to a program that is already in the list of the CAM. A new program must therefore first be added with CA_PMT(add), and after that it can be queried whether the CAM can also decrypt it.


    A quick test in cCamSlot :: CanDecrypt() immediately gave me a reply with 0x81 for the PIDs, before this patch i got no reply at all. But I have to test it more closely.


    That the AlphaCrypt Cam reacts differently, is in my opinion only because of the special firmware.


    I think, according to clause 9.5.1, the feature is not intended to determine the possibility of multiple decoding of by the CAM module.

    You are right, but indirectly, you can tell if a CAM responds to more than one program with a positive reply.


    Helmut


    Edit:

    I'm afraid my approach is not the solution. A CA_PMT (query) with CALM_ONLY like in joker_en50221_sync_cam() also deletes the previously added programs (just like I already noticed in post # 7).

    Ja, das sich die CAMs verschieden verhalten, habe ich schon bei Spielereien mit TS-Paketen bemerkt. Wenn die Daten Unsinn sind, setzt eine CAM von sich aus alle 188 bytes das Sync-Byte (0x47), eine andere nur beim 1.Packet usw.


    Das der VDR nur auf korrekte Queries reagiert ist sicher der richtige Weg da sich die CAMs beim Versuch mehr Programme als die unterstützte Anzahl zu entschlüsseln auch unterschiedlich verhalten. Das SimpliTV CAM z.B. öffnet beim 3. Progarmm das CAM-Menü mit Hinweis und Telefonnummer zur Regstrierung und stellt die Entschlüsselung der beiden laufenden Programme ein (nach abschalten der Aufnahmen und Senderwechsel gehts natürlich wieder). Und das ist ja nicht wirklich bauchbar.


    Helmut

    Eine interessante Sache.

    Es sieht so aus als würde alleine das CA_PMT query in cCamSlot::CanDecrypt() die Mehrfachentschlüsselung des CAM verhindern.

    Ich habe das "return true" in cCamSlot::CanDecrypt() wieder entfernt und die logs auf syslog umgeleitet. Bei einer verschlüsselten Aufnahme und umschalten auf einen zweiten Sender kommt ein Reply - allerdings mit 0xF1 (can decrypt, but no subscription):

    Wenn ich in cCamSlot::CanDecrypt() bei CaPmt.SetListManagment() CPLM_ONLY statt CPLM_ADD angebe, bekomme ich beim Umschalten ein Reply mit 0x81 (can-decrypt), allerdings werden dabei die PIDs des ersten Senders gelöscht (die CAIDs sind die gleichen) und die Entschlüsselung der Aufnahme wird beendet:


    Das bedeutet, das bei diesem CAM die Mehrfachentschlüsselung nur funktioniert wenn KEINE queries gesendet werden und cCamSlot::CanDecrypt() keine Prüfung vornimmt sondern sofort "true" liefert.


    Übrigens kann das SimpliTV Modul (für DVB-T2 in AT) auf diese Weise auch zwei Programme gleichzeitig entschlüsseln.


    Helmut
     


    Hab es Jetzt kurz getestet - mit den beiden Ergänzungen kann ich mit dem NEOTION Modul zwei Sender gleichzeitig entschlüsseln und aufnehmen. Es ist auch möglich auf einen dritten Sender umzuschalten, der bleibt dann allerdings schwarz - also nur Dualentschlüsselung des CAM.

    Durch das sofortige "return true" in cCamSlot::CanDecrypt() weiss ich noch nicht, ob und wann das Modul auf ein query reagiert, das werde ich dann morgen (eigentlich doch schon heute) versuchen herauszufinden.


    Helmut

    Verstehe, die "leeren" queries sind also ok .

    ich war mir mit meiner speziellen Hard- und Softwarekonstellation nicht sicher ob das nicht ein selbst gemachtes Problem ist.


    Zu "repliesToQuery = true":

    Das habe ich schon in diesem uralten Thread https://www.linuxtv.org/pipermail/vdr/2008-April/016525.html gelesen, hat aber in einem ersten Versuch nichts geholfen - kein Reply.

    ich werde mich aber damit noch einmal genauer beschäftigen da ich nicht alle darin angeführten Ergänzungen ausprobiert habe.


    Wie sieht eigentlich das Reply des CAM auf ein "leeres" query aus?

    Und kann es sein, das nur die Alphacrypt Module darauf antworten? Mit der Suchfunktion hier im Forum finde ich leider nichts Erhellendes zur Verwendung von MCD/MTD.


    Helmut

    Meine Versuche mit einem Neotion Modul MCD/MTD zu nutzen sind bisher leider erfolglos.


    Das Modul sollte Dualentschlüsselung beherschen, allerdings antwortet es nicht auf die CA_PMT query Anfragen.

    Der Grund dafür liegt vielleicht auch daran, das VDR bei mir gleich nach dem Start die query-requests an die CAM sendet, allerdings noch bevor ein Signal anliegt. Das bedeuted es sind leere Anfragen ohne Programmnummer und Pids. Danach wird in ci.c repliesToQuery auf false gesetzt.


    Nun meine Frage: ist das mit den leeren CA_PMT queries normal und wenn ja welche CAM antwortet dann (und vor allem wie) darauf - ich glaube MCD/MTD funktioniert ja mit den Alphacrypt Modulen, aber hat jemand auch mit einem "normalen" Modul erfolg?


    Hier ein kurzes Log in dem zu sehen ist, wie die 6 CA_PMT query Anfragen vor dem eigentlichen Tunen erfolgen. (mit vdr-2.3.8, ddci2 und meinem Wintv USB-CI Adapter):

    Vielleicht hat jemand eine Idee.


    Helmut


    Versuche es damit:

    - regex für grep auch mit Anker ^ für Zeilenbeginn

    - alle sed Ersetzungen mit 'g' für alle Vorkommen in der Zeile

    Code
    1. dat_neu_var=$(grep '^S ' "$info_var" | sed 's/^S //; s/ /_/g; s/\//#2F/g; s/"("/\(/g; s/")"/\)/g; s/\:/#3A/g')
    2. verz_neu_var=$(grep '^T ' "$info_var" | sed 's/^T //; s/ /_/g; s/\//#2F/g; s/"("/\(/g; s/")"/\)/g; s/\:/#3A/g')

    sieht bei mir dann so aus:


    Helmut

    Auch hier in Wien die Parameter nur vom T2 ExtensionDescriptor (direkt über USB DVB-T2 Adapter).

    MUX B2 liefert übrigens immer noch eine falsche Stream-ID - sie sollte bei allen Sendern "1" sein.


    Helmut

    Nachdem ich mich eine Zeilang mehr mit anderen Dingen beschäftigt habe hier nun ein Update des Kernel Treibers für das USB-CI.

    Um die Probleme durch blockierte Control USB-Endpunkte wegzubekommen, war das genaue Timing beim übertragender der TS-Daten herauszufinden, das hat auch etwas gedauert.

    Jetzt nach einem Kurztest sieht aber alles ganz gut aus, Kanalwechsel etc. ist nun ohne Fehler möglich.


    Im Anhang auch ein Logfile das die Infos ab dem anschließen des CI, den start des vdr und einigen Kanalwechsel (bei CA_PMT) auf verschlüsselte Kanäle zeigt.


    Helmut


    Edit:

    Das Kernel Modul heißt nun wintv-usb2ci

    Edit2:

    Ein paar Fotos wie es im Betrieb aussieht


    Also hier am älteren Notebook mit xineliboutput und OHNE Hardwarebeschleunigung macht es beim schnellen Vorlauf keinen Unterschied (der schnelle Rücklauf funktioniert vermutlich wegen meiner Hardware oder dem Plugin nicht richtig).

    Ich habe inzwischen etwas nachgelesen. Die Verwendung von posix_fadvise() wurde damals (vor mittlerweile fast dreizehn(!) Jahren) ja eingebaut

    Und hatte wie es ausssieht die ganze Zeit einen Fehler der erst seit Kernel 4.7 behoben ist:

    https://git.kernel.org/pub/scm…8e9f6d8d446427d8b7691c194


    Helmut

    Bravo, und clever mit den TS-Fragmenten.
    Testen kann ich es mangels entsprechender Hardware leider nicht.


    interessant finde ich, dass die SYNC Verschiebung genau vor einem NULL-Paket stattfindet, und - da du ja keine Fehlermeldungen oder Bildfehler hast - tsin_find_offset() offenbar immer erfolgreich ist, Anderenfalls würden ja TS-Pakete ohne dem SYNC-Byte im tsout-Ringbuffer landen.


    Das liegt am Ngene Chip der eigentlich für Audio gedacht ist und immer etwas erwartet, weil bei Audio ist das einfach so. Man hat das dann mit den leeren TS Paketen im Treiber gebastelt.

    Alles klar, habe ich nicht gewusst. Und ohne die Idle-Pakete geht es wie von nst gestestet ja wirklich nicht.



     

    Ah, jetzt weiß ich wofür dieser Idle-Buffer gut ist - er beschäftigt das CAM obwohl es eigentlich gar nichts zu tun gibt.

    Hilft jetzt aber auch nicht weiter.


    Von der CAM-Control habe ich eigentlich nicht entdeckt - das läuft ja über den cxd2099, und ob das den selben Speicher/Buffer nutzt wie die TS-Daten würde mich wundern - möglich ist natürlich alles.

    Den Offset in tsin_exchange() einfach zu überspringen wird auch nicht gut funktionieren da dann zwangsläufig das unvollständige (<188 byte) TS-Paket am Ende nicht mehr in den Tsin Ringbuffer geschrieben wird. Man verliert also bei jedem exchange 1 TS-Paket.

    Im Moment fällt mir auch nicht mehr ein, außer noch einmal über den Code zu schauen.


    Vielleicht kannst Du noch vergleichen ob es sich mit einem anderen CA-Modul genau gleich verhält.


    Helmut


    Edit:

    Doch noch was eingefallen: Kann man aus den 4 oder mehr Bytes vor SYNC irgendetwas erkennen - z.B Reste des NULL-Pakets (0x6F) oder Fragmente einer Control - Kommunikation?

    Sehr eigenartig.

    Ist der Offset gleich zu Beginn und bleibt dann gleich (also immer +188 bytes) , oder "bewegt" sich das SYNC byte ?

    Auf jedenfall ist irgendwann der tsin-Ringbuffer nicht auf SYNC ausgerichtet , dann sollte es doch zumindest einmal eine Fehlermeldung von ddci2 mit "skipped xx bytes to sync on start of TS packet" geben. Hier wird immer nur die MTD Meldung erwähnt - oder habe ich sie überlesen.


    Helmut

    Hallo,

    wenn man sich die Daten der TS-Null Pakete ansehen könnte, hätte man vielleich einen Hinweis auf dei Quelle.

    Hier eine Erweitern der MTD Fehlermeldung in der originalen mtd.c :

    Die ersten 8 Bytes werden dabei nach der Pid als zwei 32-Bit Werte ausgegeben.

    Vielleicht willst du das einmal probieren.


    Helmut