Auto Pin Plugin

  • Der code von den komischen Helpern ist ziemlich zusammengeschustert weil er wahrscheinlich von Boxen stammt die das was die 7080 kann gar nicht unterstützt, weswegen das CI handling für eine korrekte Zuordnung eben nicht wirklich optimal ist.


    Naturlich ist der code unserer Freunde dazu da primär die richtigen Tunernamen zu ermitteln. Das A1/A2 ist ja eine Spezialitäöt von 8000 und 7080 aber es soll ja Leute geben die statt dem Dualtuner einen 3. DVB-C reinsteckemn und dann macht es Sinn aus den nim_sockets die Tunernamen auszulesen.


    Aber ganz am Anfang wird das inputX einfach aus der Tuner nummer bestimmt:


    snprintf(buf, 64, "/proc/stb/tsmux/input%d", tuner_no);


    Wenn das so einfach ist und die tuner nummer der nim nummer entspricht und man ja im ciX_input immer stehen hat welcher tuner in welches CI bläst dann kann es ja nicht so schwer sein das in python korrekt nachzubauen, ausser Ihr hättet das im DreamOS total anders implementiert.


    Dann müsste ich immer nur wissen mit welchem Tuner die jeweilige serviceref gerade getuned wird, dann wüsste ich dessen tuner nummer und damit dessen korrekte inputX wo dann halt das richtige CIX reingeschrieben gehört.


    Oder einfacher - auslesen der ciX_input welcher tuner dort drinnen steht, dann daraus die tuner nummer ermittlen und damit wissen welches inputX verwendet wird.


    Ich hoffe das erklärt meine Frage besser :face_with_rolling_eyes:


    Hier noch ein Beispiel mit laufendem PIP wo jeweils ein Modul pro sender benötigt wird:


    Code
    cat /proc/stb/tsmux/ci0_input
    A1
    cat /proc/stb/tsmux/input0
    CI0
    cat /proc/stb/tsmux/ci1_input
    A2
    cat /proc/stb/tsmux/input1
    CI1


    das obere CI wird von A1 mit der nim nummer 0 befüttert, weswegen im input0 also CI0 stehen muss.
    das untere CI wird von A2 mit der nim nummer 1 befüttert, weswegen im input1 also CI1 stehen muss.

    Einmal editiert, zuletzt von Lost in Translation ()

  • Ich habe gerade das entdeckt:


    Code
    print eDVBCIInterfaces.getInstance().getTunerTsInput(0)
        	print eDVBCIInterfaces.getInstance().getTunerTsInput(1)
        	print eDVBCIInterfaces.getInstance().getTunerTsInput(2)
        	print eDVBCIInterfaces.getInstance().getTunerTsInput(3)


    was genaus A1 A2 B C ausgibt wie wenn ich es aus dem /proc auslese.


    Ist das so richtig sich den korrekten Tuner Namen für die jeweilige Tuner Num 0... 3 bzw, das input0...input3 zu holen ?


    Dann fehlt mir wirklich nur mehr die Lösung wie man für die jeweilige serviceref rausfindet welcher tuner fürs Empfangen der selben verwendet wird.


    Weil das Beispiel aus dem vorherigen Post funktioniert ja nur wenn ich vorher weis dass das was auf Tuner A1 empfangen wird auch mit CI0 entschlüsselt wird und das was auf A2 empfangen wird mit Tuner CI1 entschlüsselt wird.


    Das kann doch nicht so schwer sein das dem enigma2 auch noch zu entlocken welcher tuner gerade für was getuned wurde :face_with_rolling_eyes:


    In den Kanal-Infos auf Tuner Status wird das ja für den gerade geschauten Tuner angezeigt - allerdings lustigerweise mit NIM: A/B/C/D - also wirklich konsistent ist DMM da nicht, müsste das nicht auch A1/A2/B/C sein ?


    aus der ServiceInfo.py


    Code
    return ((_("NIM"), ('A', 'B', 'C', 'D')[frontendData["slot_number"]


    Da müsste statt den hardcoded A/B/C/D doch das getTsInput von oben verwendet werden damit es korrekt ist, oder ?

    4 Mal editiert, zuletzt von Lost in Translation ()

  • so gehts für das was geschaut wird:


    Code
    service = self.session.nav.getCurrentService()
     self.info = service.info()     	 
     self.feinfo = service.frontendInfo()
     frontendData = self.feinfo and self.feinfo.getAll(0)
     print frontendData["tuner_number"]


    Damit muss ich dann nur mehr schauen welches CIX für diese serviceref benötig wird zum Entschlüsseln gemäß der ciX.xml aus dem Assignment Plus Plugin und das in das jeweilige inputX dieser tunernummer schreiben, oder ?


    Nur damit ich nicht nochmals unnötig probiere, funktioniert das auch für andere service reference wie eine von einer Aufnahme oder dem PIP oder auch nur für die jeweils geschaute?


    Und ja ich weis das ich lästig bin, aber ich musste mir das alles erst mühsam zusammensuchen und so halbwegs zu versuchen zu verstehen wie es funktioniert :face_with_rolling_eyes:


    Aber ich habe es auch mit dem Provider CI assignment support nicht eilig, vor dem Wochenende komme ich eh nicht dazu die ganzen Erkenntnisse in eine halbwegs brauchbare neue Version vom AutoPin einfliessen zu lassen.

    4 Mal editiert, zuletzt von Lost in Translation ()

  • Streamen ausser wenn du den geschauten sender streamst ist noch gar nicht unterstuetzt. Und AutoPin laeft zwar bei dir aber es macht nichts weil kein senderassignment fuer das CI gefunden wird.

  • Ich hatte wieder mal ein bisschen Zeit daran zu basteln, muss aber nochmals fragen ob der code im vorherigen Post auch für recordings funktionieren sollte um sich die Tuner Nummer einer Aufnahme zu holen ?


    wenn ich

    Zitat

    service = self.session.nav.getCurrentService()

    durch

    Zitat

    service = self.session.pip.getCurrentService()

    ersetze dann kann man auch die tuner nummer fürs Pip Afragen, womit ich schon sauber 2 CI module zwischen geschautem und PIP Sender richtig zuteilen kann.


    Hole ich mir aber das service für eine Recrding ref so:

    Zitat

    recordingservice = self.session.nav.recordService(recording_reference)

    Dann gibt ein

    Code
    print recordingservice.FrontendInfo

    nichts zurück, was mache ich dabei falsch ? Weil wenn die FrintendInfo schon leer ist brauche ich mit FrintendData gar nicht mehr nach der tuner number fragen.


    Die Recording reference hole ich mir vorher so:

    Zitat

    def onTimerEntryStateChange(self,timer):
    if hasattr(timer, "Filename") and not timer.justplay:
    if timer.state == TimerEntry.StatePrepared:
    recording_reference = timer.service_ref

    Ist dabei StatePrepared zu früh und der Tuner noch gar nicht entschieden, wobei ein StateRunning da auch nichts drann ändert ?

    6 Mal editiert, zuletzt von Lost in Translation ()

    • Offizieller Beitrag

    Hi,


    nein... geht so nicht wie du es machst.. du startest da gerade eine neue Aufnahme.


    Such mal nach nav.getRecordings... da bekommst Du eine Liste aller Aufnahmen die gerade laufen.


    Das sind direkt iRecordableServicePtr...


    Da musste dann allerdings erstmal wieder mit info ... sReference den passenden raussuchen... denn es könnten ja mehrere Aufnahmen laufen.


    Ansonsten gibt es auch einen Callback den du registrieren kannst... damit würdest du automatisch sobald eine neue Aufnahme startet informiert.. und bekommst direkt den iRecordableServicePtr....


    Aber ich finde nach wie vor den ganzen Ansatz den du da verfolgst nicht wirklich gut ... nur um es mal gesagt zu haben ,)


    cu

  • Das sind direkt iRecordableServicePtr...


    und bekommst direkt den iRecordableServicePtr....

    Danke, das war das fehlende Puzzlestück - ich kann also timer.record_service verwenden statt timer.service_ref


    Jetzt funktioniert das auch für Timer dem enigma2 die verwendete Tuner Nummer und damit das richtige inputX zu entlocken um ... nachzuhelfen.


    Und ja ich weis das man über die Sinnhaftigkeit des Ganzen mehr als diskutieren kann, aber solange es den Zweck erfüllt und ich mit 2 'virtuellen' CIs schauen plus Aufnehmen kann - und ohne die 'Hilfe' derzeit eben nicht :thumbs_up:


    PS: Ist schon abzusehen wann der Fix damit man auch für servicerefs die nicht gerade abgespielt wird sich den Provider über enigma2 holen kann eingechecked wird ?


    Provider Name von serviceref ?


    Weil dann hätte ich eigentlich alles was ich im CI Assignment Plus letzendlich implementieren wollte soweit zusammen, die CAID Zuweisung macht da meines Erachtens sowieso keinen Sinn, aber bei großen Providern ist es einfach zu mühsam alle Sender in die ciX.xml zu machen.

    8 Mal editiert, zuletzt von Lost in Translation ()

  • Ich habe mal meinen aktuellen Erkenntnisstand bei der CI Module Erkennung in einen 0.8 Testkit gemacht.


    Da sollte wenn jetzt ein CI nicht zuständig ist (sprich der Sender nicht
    dem CI manuell im CI Assignment Plus zugeordnet wurde) dieses auch
    nicht angesprochen werden, aber erstmal sehen ob es so überhaupt besser
    funktioniert als die bisherigen Versionen.


    Die Zuordnung ist jetzt auch dynamisch, sprich wenn man was ändert muss
    man nur einmal Zappen damit es ektiv ist, enigma2 restarten ist nicht
    mehr nötig.


    Provider Erkennung gibt es aber immer noch keine, Ghost muss erst sein
    Versprechen einlösen den code einzuchecken mit dem man für eine
    Serviceref den provider zurück bekommt.


    LG
    gutemine

  • Hi, AutoPIN klappt bei mir jedoch muss ich auf meiner DM7080 immer mit OK bestaetigen wenn die Sternchen erscheinen. Das waere ja kein Problem aber wenn ich auf meiner DM800 via Partnerboxfunktion auf einen Sender der DM7080 gehe der eine JS PIN Abfrage benoetigt dann bleibt es schwarz. Hat wer eine Idee?

  • Dann benutzt du eine verbogene keymap weil mit originalimage geht das problemlos ohne ok. Und streaming Support habe ich noch nicht eingebaut. Erst muss mal aufnehmen und schauen gehen dann kommt das pip drann und dann erst habe ich Zeit fuers streamen schon weil ich das nicht benutze und es daher nicht eilig habe ...

  • Nachdem mir selber das Sender zuordnen auf den * ging und ich nicht
    warten wollte bis Ghost die entsprechende Routine eincheckt, habe ich
    mir das überprüfen der Senderzuordnung auf ein CI über den Provider über die alte lamedb in einer 0.10 vom AutoPin einfach selber eingebaut.


    Jetzt funktioniert das CI Assignment Plus eigentlich so halbwegs wie ich mir das vorstelle ... und wie enigma2 das im DreamOS eigentlich auch ohne Hilfe können sollte.


    LG
    gutemine

    Einmal editiert, zuletzt von Lost in Translation ()

  • Jetzt funkt es auch beim streamen (hatte im CI+ Dream Menue die PIN nicht eingetragen). Vielen Dank, Gutemine. Echt cooles PlugIn. Koenntest du evtl. noch das autom. wegschalten der Message 535 einbauen? :winking_face:

  • Ich habe halt noch eine 0.16 gemacht wo man auch die 535 Messages wegdrücken lassen kann.


    Ob das wirklich Sinn macht ist eine andere Sache ...

  • Ghost


    Ich habe nachdem sich keiner der Sachen angenommen hat den Ratschlag befolgt und der Software zum Virtualisieren der CI module eine routine zum Auslesen der ciX.xml spendiert, dann ist auch das tsmux handling OK, und die Antwort mit der PIN habe ich auch eingebaut.


    Du hattest recht ... so ist es ... besser :grinning_squinting_face:


    LG
    gutemine

  • Also ich habe das jetzt ausgibig getestet, die 510 Nachrichten des nicht zuständigen Moduls sind damit auch Vergangenheit und so kann man auch problemlos unterschiedliche PINs pro Modul haben.

  • das aktuelle Auto Pin 0.20 unterstützt jetzt auch das neueste Helferlein
    mit dem der PIN pro Modul automatisch eingegeben wird und das auch das
    CI Assignment berücksichtigt.


    Womit es eigentlich obsolet geworden ist ...

  • Nachdem das einzige was noch im Autopin Plugin Sinn macht die PIN eingabe ist bin ich am überlegen ob man die nicht auch ins Common Interface Menu auslargern könnte.


    Das sollte dann so wie im Anhang aussehen.


    Wäre es möglich das in den Standard aufzunehmen ?


    Oder wenigstens in der Ci.py die entsprechenden config werte mit aufzunehmen damit es in allen Images gleich ist und ich das nicht vom Plugin aus überschreiben muss?


    Einfach die eine Zeile in der InitCiConfig


    Code
    config.ci = ConfigSubList() 
        	for slot in range(MAX_NUM_CI):
                	config.ci.append(ConfigSubsection())
                	config.ci[slot].pin = ConfigInteger(default = 0, limits=(0,9999))
                	config.ci[slot].canDescrambleMultipleServices  ....