Ja, die README werde ich wohl erst einmal anpassen, das stand noch auf meiner Liste.
Das mit dem Repo weiß ich nicht so richtig, soll ich mich da einfach hinzufügen lassen oder müsste man das nicht mit dem letzten Maintainer abstimmen?
Posts by kamel5
-
-
-
Bei den Logs von ddci2 habe ich das so gerechnet. Das sind zwar alles nur ca. Werte, die auch schwanken, kann aber durchaus passen:
bezogen auf 1Min.
1 Kanal HD: 1449186 - 1225169 ergibt ~ 224000
1 Kanal SD: 214624 - 88678 ergibt ~ 126000
2 Kanäle HD+SD: 825863 - 477308 ergibt ~ 349000
Das ist durchaus plausibel.
kamel5
-
Was du vielleicht selbst herausfinden kannst ist, ob TS-Pakete mit den Pids von beiden Programmne beim "Host" landen.
Wenn ich nicht falsch liege dann mit so etwas wie Peek13(tsPacket+1) in TsPostProcess() des Hosts.
Ok, das überfordert mich doch etwas. Ich bin schon froh, das ich dem Ganzen so halbwegs folgen kann. Da warte ich lieber auf den Patch oder Du sagst mir, was ich genau wo einbauen muss.
In diesem Zusammenhang ist mir noch eingefallen, das ja auch das ddci2-plugin Debugging-Optionen hat. Ich habe das jetzt mal mitlaufen lassen und es gab da aus meiner Sicht keine Ungereimtheiten:
Der Eine ist ein HD-Kanal, der Andere ein SD-Kanal. Wie man in der Zeiteinheit von 1min sieht, gehen tatsächlich in der Zeit, wo 2 Kanäle aktiv sind, eine Summe von Paketen beider Kanäle durch das Cam, es wird also erst einmal nichts geblockt.
Wenn ich auf einen verschlüsselten Kanal schalte, gibt es am Anfang noch solche Meldungen, ein Bild ist aber trotzdem schon da und sie hören auch nach einer gewissen Zeit auf:
kamel5
-
Hast Du das schon gesehen? Als temporäre Lösung.
-
Du musst Dir mal überlegen, wo Du die Kernel-Sourcen her bekommst.
Das was Du dort hast, sind die falschen. Du musst für den installierten Kernel 4.18.0-18-generic die genau dazu passenden Sourcen besorgen. Wie Du das bei Ubuntu machst, kann ich Dir nicht sagen. Wenn Du nicht die dazu passenden hast, funktioniert das in keinem Falle.
kamel5
-
So, ich habe das Git gerade aktualisiert, es sollte jetzt wieder bauen.
Da war ich wohl an einer Stelle schon weiter beim Ändern.
-
Ich bekomme den gleichen Fehler. Ich baue hier immer mit einem etwas anderen Stand, da ist mir der Fehler wohl durchgerutscht. Ich schaue mal woran es liegt.
-
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
-
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
-
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
-
Nach dem make localyesconfig muss ich noch make -j4 modulesmachen oder nicht.
Ja, musst Du machen.
Gemäß der Fehlermeldung fehlen Dir aber einige Headerdateien. Wie Du bei Deiner Distro dazu kommst, kann ich Dir leider nicht sagen.
-
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
-
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
-
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
-
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
-
Mache ich dann mit dem Kernel-Source von dort https://github.com/s-moch/linux-saa716x/tree/saa716x-4.15 weiter
Warum fängst Du immer wieder damit an? Aus dem Git brauchst Du nur den Patch.
Du hast doch jetzt einen gepatchen Distro-Kernel-Source. Da machst Du jetzt weiter mit 'make localyesconfig, da wirst Du auch schon nach den Modulen gefragt.
make menuconfig ist optional zum überprüfen.
Die entstehenden *.ko Dateien dann nach /lib/modules in das passende Kernel-Verzeichnis kopieren. Und zum Schluß ein depmod -a.
Wenn alles passt, werden die Treiber dann geladen, wenn Du den Rechner neu startest.
Und auch die entsprechenden Firmware-Dateien nicht vergessen.
Und dann noch beachten, das Du das Ganze nach jedem Kernel-Update neu machen musst.
-
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
-
cd /usr/src/linux-source-4.15.0/
patch -p1< /media/SicherBehalten/uwe/Installation/Kernel/KernelBauen/NEU18.04/NeueS_oren/v4.15...saa716x-4.15.diff
can't find file to patch at input line 5
Hast Du denn in dem Ordner auch die Kernel-Sourcen liegen, das sieht so aus, als wenn da keine vorhanden wären.
Wie Du bei Deiner Distro zu den Kernel-Sourcen kommst, kann ich Dir leider nicht sagen, ich nutze hier Fedora.
Wenn die Sourcen dort lägen, wäre zumindest das patch -p1... soweit richtig.
-
Ich wechle in den Ordner 'linux-saa716x-saa716x-4.15' hinein und mache folgendes
Das sieht so aus, als wenn Du den Kernel-Source von dort https://github.com/s-moch/linux-saa716x/tree/saa716x-4.15 herunter geladen hast.
Dann ist der Patch bereits enthalten.
Ich würde ja einen Kernel-Source von Deiner genutzten Distro nehmen und dann den Patch einspielen, sonst musst Du alle Kernelparameter händisch konfigurieren.
