Kommt drauf an was hier nicht diskutiert wird womit du dir selbst helfen musst.

Ich habe jetzt endlich mal Zeit gehabt rauszufinden wie man so wie es sich gehört ohne Verzögerung zwischen der Benutzung von 2 verschiedenen CI Modulen hin und her zappen kann ohne ständig dem enigma2 das unbenutzte Modul wegzunehmen (was dann eben Zeit neim Zappen zwischen Modulen kostet).

Nur testen müsste das wer ... DANN gibt es auch eine 0.6 vom Auto Pin

EDIT: Ich könnte dadurch auch ein wieder halbwegs funktionierendes PIP anbieten, wo für beide Sender wenigstens ein unterschiedliches CI modul verwendet werden kann

Einer ist ein bisschen wenig und man braucht eigentlich 2 CI Module damit das Testen Sinn macht.

Wenn es aber eh sonst Keinen interessiert, habe ich die 0.6 so wie sie derzeit ist bei OoZooN hochgeladen.

Die Zuordnung der CI Module zum Anschauen und Aufnehmen funktioniert damit schon ziemlich problemlos und auch der PiP support ist vorbereitet, aber den Teil brauche ich selber nicht wirklich, womit ich das auch nicht getestet habe.

Der Vorteil es über das /proc/stb/tsmux/inputX zu machen ist halt das es besser performt und man sich dann um die DreamCrypt Kartenschächte keine Sorgen machen muss, womit der Teil wieder rausgeflogen ist.

LG
gutemine

Nein aber in der 0.6 wird der Ansatz mit dem Verstecken von CI Modulen über Sockets umbenennen gar nicht mehr verwendet, sondern übers /proc/stb/tsmux/inputX so wie es sich eigentlich gehört das richtige CI aufgezwungen.

BITTE lies auch was ich bei OoZooN geschrieben habe, die 0.7 hat gar keine Software CI Einstellung mehr weil das nicht mehr nötig ist.

Im Prinzip hast du recht, nur macht das enigma2 es bei meinen 2 Modulen nicht richtig womit dann nichts entschlüsselt wird.

Und sooo kompilziert ist die logik im enigma2 auch nicht, es wird mit input0 begonnen und dann gestacked wenn ein recording dazu kommt oder ein PIP. Und so habe ich auch rausgefunden was für Fehler enigma2 gemacht und die halt mit echo CI0 oder CI1 ins jeweilige InputX gefixed bis ich wusste was zu proggen ist.

Kompliziert wird es halt bei mehreren recordings gleichzeitig und PIP und .... nur das verwende ich halt selten.

Für die Brot und Butter Konfig, sprich ich will frei Zappen können und immer das richtige modul gemäß der zuordnung für das entschlüsseln verwenden reicht das was ich geprogged habe aus, für eine Simple Aufnahme wo man sonst nur FTA schau oder die box ins standby ist auch.

Das Haupt Problem ist halt das für die 'Virtuellen Module" über die wir hier besser nicht sprechen plötzlich im CI Assignment gar keine CIs mehr erkannt werden und dadurch der Code im enigma2 auch gar nicht richtig funktioniert, womit man halt ein bisschen 'nachhelfen' muss

Und ich habe wirklich einige Zeit gebraucht um rauszufinden wo und und vor allem wie man es im /proc macht ohne allzuviel damit kaputt zu machen.

Aber ja natürlich wenn Ihr das im enigma2 fixen würdet wäre es .... besser .... Schon weil die Mitbewerber zu blöde dafür sind und bei diesen virtuellen Modulen immer das was Sie aufnehmen auch schauen müssen und dann nicht in meinem Code so einfach nachlesen könnten wie simpel man das eigentlich fixen kann ...

Insofern schenkt Ihr da im Moment ein Alleinstellungsmerkmal der 7080 her, das relativ leicht zu fixen wäre.

EDIT; Nur zur Motivation - Ich habs auch mal wieder in einem Image auf der 7080 probiert das auf dem alten offenen enigma2 stand basiert ... da funktioniert es auch ohne 'Hilfe'

Nein das war nur zur Motivation für Ghost

Ich muss mich auch an die Boardregeln halten ...

Aber es gibt scheinbar böse Software die dem enigma2 die CI Module wegnimmt und durch virtuelle ersetzt und für die funktioniert das CI Assignment dann halt logischerweise nicht so wie für die echten vom enigma2 direkt verwalteten CI Module. Und mein Plugin hilft halt nach das es wenigstens so halbwegs wieder funktioniert.

Ohne Plugin steht derzeit immer das letzte also CI1 in der input0 - was halt nur in der Hälfte der Fälle stimmt.

In den Open* Images für die DreamOS Boxen ist das anders gelöst (da wird nur das /dev/dvb/adapter0/ca0 verwendet und keine sockets in /run/ca ) womit das enigma2 CI handling weiterhin funktioniert.

Es wäre halt ein grosses Plus für das CI handling im DreamOS wenn Ihr das sauber(er) lösen könntet

LG
gutemine

Ich habe das im Prinzip durchaus verstanden, aber man muss ja nicht immer die empfohlenen Lösungen umsetzen - Griechenland ist da ein gutes Beispiel im Moment.

Es funktioniert ja so wohl die Variante das nicht benotigte Socket temporär umzubennennen als auch in der tsmux/inputX nachzuhelfen, wobei beides natürlich an die bereits aufgezeigten Limits stösst.

Ich wäre zwar durchaus in der Lage das im C Code anzupassen, aber das stösst schon ein bisschen an die Grenzen dessen was meine Betroffenheit in diesen Grauzonen zulässt.

Ausserdem ist es eben auch eine challenge das am enigma2 vorbei korrekt zu lösen

Ich habe nachgesehen wie das unsere Freude machen:

https://github.com/openatv/eni…ster/lib/dvb_ci/dvbci.cpp

Die parsen also was in der nim_sockets steht - sprich welcher Tuner welches socket bekommen hat. Ich kann doch in Python auch nachfragen welcher Nim Gerade welche serviceref abspielt und dann hätte ich alle nötigen Infos auch AUSSERHALB von der bösen Software und dem closed source enigma2 OHNE die komplette Logik nachzubauen. Und dann kann ich mit der Kanalzuordnung aus der ciX.xml auch korrigierend eingreifen ohne was durcheinander zu bringen.

Oder habe ich da noch immer einen Denkfehler