Beiträge von jasminj

    Ich habe gerade den Hinweis bekommen, dass es sich um einen Bug im Alpha Crypt CAM handeln könnte.

    Das hängt aber vom Stream ab und ob Frames mit einem Adaptation Field (ohne Inhalt) aufgefüllt werden.

    Man könnte das zwar im VDR mit einfügen eines Null Paketes lösen, aber ich halte das schon für eine sehr spezifische AC Anpassung und die sollte nicht in den VDR. Mal warten was Klaus dazu sagt.


    Ich stehe nach wie vor auf dem Standpunkt das VNSI Plugin sollte einen Schalter bekommen, der den CAM Reset verhindert. Oder besser die Logik umkehren und den Reset nur dann auslösen, wenn die Option aktiviert wurde.


    LG,

    Jasmin

    Danke onur für diesen Hinweis!

    Vielleicht könnte einer der Betroffen das ausprobieren, damit wir das Problem debuggen können.

    Ich bin nach wie vor nicht begeistert, dass VNSI einen CAM Reset einleitet.

    Solche Workarrounds sollte man mit einer Option abschaltbar machen. Dann können sich die User selbst helfen.


    LG,

    Jasmin

    Allerdings klappt es mit Kernel 4.14 noch nicht. Hier hat es Probleme bei "apply_patches" gegeben, was ich aber noch nicht genauer analysiert habe.

    Ich habe ja das Warten des media-builds geerbt, nachdem Hans keine Zeit mehr hat.
    Gestern Abend hatte es eigentlich für Kernel 3.8 funktioniert ...

    Hab mir das jetzt angesehen und ... Asche auf mein Haupt ... ich repariere es gleich. Melde mich dann wieder hier.

    Ich kann mittlerweile auch bestätigen, dass der Fehler mit der Offsetverschiebung durch die Anpassung nicht mehr auftritt. Klaus Patch ist somit nicht mehr notwendig.

    Nun ja so einfach ist das nicht.

    Der Patch ist nur dann nicht mehr notwendig, wenn man einen ganz neuen Treiber aus dem media-git verwendet. Sprich The Bleeding Edge und noch nicht mal released.

    Hat jemand aber einen alten Kernel (Ubuntu 14.04 verwendet 3.13), dann braucht man den Patch schon.

    Und ich habe momentan keine Zeit mein media-build DKMS auf Stand zu bringen.

    Hatte allerdings einige Schwierigkeiten, das ganze für Kernel 4.14.12 zu kompilieren. Es gab hier Probleme mit em28xx-dvb.o.

    Der media-build ist wieder einmal kaputt. Ich arbeite aber daran, sonst kann ich kein neues DKMS releasen, weil das hätte ich geplant nach den ganzen tollen Erweiterungen im Kernel.


    LG,

    Jasmin

    Beide vorgeschlagenen Patches lösen das Problem.

    Sorry, aber Bits einfach löschen die ist keine Lösung. Man muss die Ursache finden.


    Ich habe mir mal schnell ddci2 nochmals angesehen und bei MTD ist die Erkennung von verschlüsselten Paketen nicht aktiv.

    Also ist mal sicher, dass es tatsächlich nicht entschlüsselte Pakete gibt. Nachdem der Audio/Video Strom bei Streamdev aber funktioniert, sind das wahrscheinlich andere Pakete.


    Jetzt wird es schwierig, weil ich nicht so sattelfest bin mit den Paket Typen.

    Ich würde mal eine Debug Ausgabe im VNSI Plugin dazu basteln, die die PID ausgibt, wenn TsIsScrambled true liefert (bekommst du mit dem Macro "TsPid"). Wenn die unter 0x20 ist, dann kann ich was damit anfangen.


    Allerdings nutzt uns das nicht viel ohne die PMT für das eingestellte Programm, wenn die PID >=20 ist.

    Wenn man den ganzen Stream irgendwie auf die Disk speichern würde, dann könntest du den mit "DVBinspector-1.9.0" analysieren. Der sagt dir dann auch welche PIDs was sind.

    Auf die Disk speichern bedeutet im VNSI Plugin an der Stelle wo die Daten rein kommen, alles in ein File zu schreiben. Musst googeln wie man ein File aufmacht und dann drauf schreibt (sorry, aber mehr kann ich dir nicht sagen, weil ich kaum Zeit habe und auch krank werde/bin).

    Ich vermute, dass da einfach irgendeine PID keine ECMs bekommt, weil VDR die zugehörige ECM PID nicht vom Mux bestellt und das CAM diese dann nicht entschlüsseln kann.

    Wenn diese noch immer verschlüsselte PID unwichtig ist, dann kann man die auch einfach im VNSI Plugin filtern. Wobei es besser wäre zu ergründen warum die überhaupt vom VDR kommt.


    Edit:

    Noch ne Idee: Das CAM braucht Zeit! Vielleicht ist VNSI nur zu ungeduldig.

    Ich hab jetzt nach dem ganzen geschreibsel nochmal darüber nachgedacht und verstehe nicht warum VNSI überhaupt TsIsScrambled so verwendet, dass es das CAM resetiert. Es mag ja sein, dass man verschlüsselte Pakete nicht via VNSI übertragen darf, also würde ich den Returnwert so ändern, dass dieses eine Paket schlicht verworfen wird und Punkt. Dann hat das keine Konsequenzen, weil der VNSI Client könnte damit sowieso nichts anfangen.

    Dann verkraftet das VNSI Plugin auch die anfänglich kommenden verschlüsselten Pakete. Und wenn die zwischendurch auch kommen sollten (siehe Hinweis zur PID Ausgabe weiter oben), dann kann man ja immer noch weiter untersuchen warum.


    LG,

    Jasmin


    VDR ist ein wirklich tolles Framework und seit der MTD-Unterstützung von Jasmin im ddci2 Plugin

    Da lassen wir mal die Kirche im Dorf! Klaus hat MTD in den VDR eingebaut, weil es da besser hin gepasst hat. ddci2 realisiert nur die Schnittstelle für die DD CI Hardware.


    Das Problem liegt an einem TsIsScrambled() Aufruf, der bei den genannten Sendern tatsächlich häufiger true zurückliefert.

    Also da frag ich mich sofort warum da verschlüsselte Pakete kommen. Wenn dem wirklich so ist, dann müsste ddci2 das auch ausspucken. Man muss ddci2 nur mit entsprechenden Debug-Flags starten (siehe README).

    Wenn das wirklich vom CAM kommt, dann frag ich mich wieso und dann ist der Stream ja eigentlich unbrauchbar, weil eben ein paar Pakete fehlen und das kommt bei MPEG ned guat. Im Grunde erübrigt sich da jedes gefrickel hinterher!

    Sagt ddci2 allerdings nichts, dann hat das VNSI Plugin beim Erkennen der Bits ein Problem und man muss suchen warum das so ist.

    Das manuelle Löschen des Scrambling Control Bits über --clrsct im ddci2 Plugin hat allerdings keinen Effekt, wenn MTD aktiv ist (Link).
    Ich sehe zwei einfache, aber unschöne Lösungen.

    Das Löschen der Bits ist keine Lösung! Wenn das CAM nicht entschlüsselt, dann ist das Paket unbrauchbar, egal ob die Bits gelöscht wurden oder nicht.


    Vielleicht sollte aber eher die Ursache des Problems analysiert werden, anstatt es nur zu kaschieren.

    Na DAS meine ich auch!

    Wie gesagt, zuerst mal ddci2 ausgeben lassen, ob die Pakete tatsächlich verschlüsselt sind.

    Wenn nein -> debug VNSI

    Wenn ja, dann muss man mal herausfinden, ob das CAM zu langsam ist, oder was da genau mit dem ECMs passiert in dem Moment, an dem nicht entschlüsselt wird. Das ist allerdings nicht trivial.


    jasminj Kannst du das Problem besser überblicken? Was ist deiner Ansicht nach der beste Fix?

    Siehe oben. Man kann erst etwas fixen, wenn man weiß was das wirkliche Problem ist. Ich habe dir ein paar Hinweise gegeben und wenn deine Kombination aus DD CI und CAM das nicht entschlüsseln kann, dann wird man das nicht in Software lösen können.

    Im Grunde musst du in die SW rein graben, verstehen was passiert und es dann lösen.


    Und mal nur so beiläufig gefragt: Die Treiber von nst verwendest du?


    LG,

    Jasmin

    muss dazu aber ubuntu, vdr und kodi komplett neu aufsetzen, Wenn ich das hinkriege teste ich und werde berichten ....

    Das klingt ja mega aufwändig!

    Also ich will dich ja nicht bremsen, aber Daniel hat das schon sehr ausgiebig getestet und wenn das bei dir bedeutet das System nochmals umzustellen, dann würde ich das lassen.


    Auf der anderen Seite müsste es ja reichen die alten Karten in das neue System zu stecken und mal mit den orignal Treibern zu testen. Da müsste es dann Fehler geben. Dann steigst auf die neuen Treiber von nst um und dann sollte es gehen.


    LG,

    Jasmin

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

    Nein das ist nicht der Grund.
    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.


    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.

    Ein Paket verlieren geht gar nicht, dann ist der Stream kaputt!

    Wenn man ohne zusätzlichen Buffer auskommen will, dann muss man eben den Rest (immer <188 Bytes) in ein kurzes Array umkopieren und beim nächsten Pakerl dann als erstes in den Output Buffer schreiben. Und man müsste immer überprüfen, ob der Offset noch passt. Das kann man aber recht billig lösen und macht das ddci2 Plugin auch.


    LG,
    Jasmin

    Nein das passt so, weil "ptr" ein "u32 *" ist und somit ein += 1 in wirklichkeit den Pointer um 4 Byte verschiebt.

    Deshalb muss man eben "+= (188/4)" schreiben, wenn man den Pointer um 188 Bytes verschieben möchte.

    Die Length ist aber die Länge in Bytes und deshalb gehört dort ein "+= 188".


    Einer der Pitfalls bei der Pointer Arithmetik in C ;)


    LG,

    Jasmin

    Ich kann gerne ein Droppen dieser Pakete beim Lesen vom DVB-Device einbauen.

    Hat eigentlich jemand getestet ob die NULL Pakete aus dem DVR Device gekommen sind oder vom CI/SEC Device, also nach dem CAM?


    Aber anscheinend haben wir inzwischen kein System mehr, auf dem dieses Problem auftritt und mit dem wir es testen könnten.

    Na ja, Daniel bekommt eine ngene Karte, aber ich weiß nicht ob er Zeit hat sich das anzuschauen.
    Wichtig wäre eben zu wissen woher die NULL Pakete kommen, weil im TS Stream vom Satelliten sind die nicht drinnen.

    Und wenn du den Filter nur nach dem DVR Device lesen einbaust, es wird aber vom CI/SEC Device produziert, dann haben wir die Pakete immer noch. Man müsste also auch die Pakete die aus Decrypt heraus purzeln auf NULL Pakete untersuchen.


    LG,
    Jasmin

    Na ja, TVH ignoriert solche Pakete auch, allerdings nur beim Lesen vom DVB Device.

    Auf der anderen Seite könnten diese aber auch vom ngene Treiber hinzugefügt werden, weil sonst keiner das Problem hat. Und wenn es das CAM erzeugen würde, dann würde das auch bei anderen auftreten.

    DD wird das im ngene Treiber nicht fixen und ich kann das nicht suchen, weil ich weder die Hardware, noch ein Datenblatt von der Karte und den verbauten Chips habe.


    Selbst wenn es ein Treiber Problem ist, so kann man keine existierenden alten Kernels patchen, somit sollte es das UserSpace Program entfernen, so wie TVH das auch tut.


    Man könnte es auch ins ddci2 Plugin einbauen, aber:

    Ich weiß jetzt nicht ob der ngene Treiber auch das redirect unterstützt, aber falls ja, dann muss man das im VDR filtern, weil man dann ohne ddci2 Plugin arbeitet.


    LG,

    Jasmin

    Ich kann mir nämlich nach wie vor nicht erklären, woher diese Pakete kommen sollen...

    Vielleicht sind es NULL Pakete.

    In TVHeadend findet sich dieser Code:

    Code
    1. /* Ignore NULL packets */
    2. if (pid == 0x1FFF)
    3. goto done;

    Vielleicht sind es NULL Pakete.

    Man könnte in ddci2 (oder schon im VDR) vor und nach dem CAM auf diese Pakte überprüfen und damit herausfinden, ob diese Pakete vom ngene Treiber oder der Cine 5.5 erzeugt werden. Könnte ja sein. Ich meine wenn sie am Eingang von ddci2 nicht da sind, am Ausgang aber schon.

    Wie schon weiter oben gesagt, der ngene Teil im Treiber ist mangels Hardware nicht besonders getestet worden.

    Und der Original DD Treiber kann die ngene Karten gar nicht mehr (soweit ich mich erinnere).

    LG,

    Jasmin

    Falls du es nochmals mit yaVDR versuchen möchtest, könntest du nach der Installation mal nachschauen, ob du überhaupt eine Netzwerk Device hast.

    Kannst du mit "ifconfig -a".

    Wenn das da ist, dann kannst du das Netzwerk ja manuell konfigurieren.

    Wenn nicht, dann ist es ein Treiber Problem.

    LG,

    Jasmin

    Vielleicht könnten die yaVDR Entwickler eine 0.6.2 machen, die dann mein media-build-dkms verwenden, statt dem alten von Oliver.

    Eigentlich war die Intention des neuen DKMS Paketes, es für yaVDR zu verwenden.


    nst hat in der Zwischenzeit wieder einige Patches von DD in den Kernel gebracht und auch einige Unschönheiten entfernt. Wäre Zeit für eine 0005 Version des DKMS Pakets. Ich bin derzeit auf Urlaub und kann deshalb bis Februar kein neues bauen.


    LG,

    Jasmin