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

Für die TT-S2 1600 und den stv090x-Treiber habe ich diesen Patch um die DVB-API 5 Dezibel-Werte zu bekommen. Die beiden Funktionen von V3 habe ich auskommentiert.

Helmut

Hi and thank you both for your input.

9000H schrieb:

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.

Yuri666 schrieb:

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

Hallo Yuri666
Danke, das Dokument kenne ich und hab auch schon gelegtlich darin nachgelesen - z.B. die max. response Zeiten auf ein CA_PMT(query). Mir ist aber im Vdr-Code nicht Verdächtiges aufgefallen.

Hast du irgendeine Vermutung woran es liegen könnte ?

Helmut

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

Ich bin über die Feiertage noch nicht dazugekommen, werde es mir aber heute Abend ansehen

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

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

Hat etwas gedauert, aber nun auch auf GitHub:

https://github.com/siricco/usb2ci

nst schrieb:

Und Du kannst immernoch über die ganzen "magischen URIs" von GitHub Code-Tarballs bereitstellen, wenn es was zu testen gibt

Das und andere Möglichkeiten muß ich erst herausfinden, hab mich mit GitHub noch nicht so genau beschäftigt.

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

kls schrieb:

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.

jasminj schrieb:

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