erweiterte Funktionen im PermanentTimeshift-Plugin

  • VirtualZap hat glaub so ein disconnect für den renderer drin. Du musst den disconnecten nicht den screen.

    Gruss
    Dre


    Boxen (im Einsatz): DM920, DM900, DMOne
    Developer Project Merlin - we are OpenSource

  • @Reichi
    Das ist die "nachgebaute" neue Source für das PTS.
    Die findest du in der zip in diesem Post:
    erweiterte Funktionen im PermanentTimeshift-Plugin


    Die baut sich glaub ich auf dem "CurrentService" auf.
    Als Vorlage hab ich die Source aus dem EMC genommen.
    Gut möglich, dass dort dass ja nicht benötigt wird, da da ja zumindest immer der Display Screen sichtbar ist, solange ein Video abgespielt wird.


    Wo müsste man das onHide denn dann noch reinnehmen?


    Grundsätzlich scheint es aktuell ja beim .hide() aufzuhören.
    Aber erst, wenn es vorher ein .show() gab.
    Denn mit dem "Trick" direkt nach dem .__init__ ein .show() und gleich .hide() gibt es kein Abfragen mehr.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Ist hier vielleicht auch eine Besonderheit, wo ein Screen mit .__init__ gestartet wird, der aber erst später angezeigt wird und bis dahin ausgeblendet bleibt.
    Da wird vermutlich direkt beim .__init__ die Source connected, obwohl der pvrStateDialog gar nicht sichtbar ist. Erst nach einem .show() und .hide() trennt er richtigerweise wieder.


    Kann man denn im Screen.__init__, wo die Source angeben wird
    self["Service"] = PTSCurrentService(session.nav, parent)


    im Anschluss die Source trennen?


    Geht das da dann mit disconnect() ?
    Denn bei einem .show() müsste sie sich ja wieder automatisch verbinden, oder?

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • ich denke in einem on layout finished wuerde ein simples hide mehr sinn machen, in einem __init__ koennen sonst komische sachen passieren.

  • Das ist das komische Screen-Konstrukt von hier:
    erweiterte Funktionen im PermanentTimeshift-Plugin


    Der Screen wird nach einem GUI-Neustart ja gar nicht angezeigt, sondern bleibt bis zum Drücken der "Pause"-Taste ausgeblendet.


    Aber das mit dem onLayoutFinished werde ich nochmal probieren (leider ist die Box heute Abend blockiert).
    Wobei ein .hide() im Plugincode erst erfolgreich war (bezüglich des Trennens von der Source), wenn es vorher ein .show() gab.


    Wie gesagt, wenn ich direkt nach dem Einbinden des InfoBarTimeshiftState-Screens ein .show() und gleich danach ein .hide() mache, wird die Source sauber getrennt und es gibt im TV-Mode nach GUI-Neustart keine Abfragen über die Converter.
    Eigentlich reicht mir das ja mit dem .show() und direkt noch .hide() :winking_face:


    Aber ich würde dennoch gern den Hintergrund des komischen Verhaltens verstehen wollen.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Hier nochmal die Zusammenfassung der relevanten Code-Passagen.


    Das ist der Code, mit dem es jetzt funktioniert (also nach dem GUI-Neustart im TV-Mode keine ständigen Abfragen der Converter).
    Das Entscheidende sind die beiden letzten Zeilen:

    Python
    class InfoBar(InfoBarOrg, InfoBarTimeshiftState):
    	def __init__(self, session):
    		print "=== pts InfoBar__init__"
    		self.pts_last_SeekState = 0
    		InfoBarOrg.__init__(self, session)
    		InfoBarOrg.instance = self
    		InfoBarTimeshiftState.__init__(self, self)
    		#do deactivate the permanently converter-calls from screen after gui-restart in tv-mode
    		self.pvrStateDialog.show()
    		self.pvrStateDialog.hide()


    Das sind die Classes die bei InfoBarTimeshiftState.__init__ dazugehören

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

    3 Mal editiert, zuletzt von Sven H ()

    • Offizieller Beitrag

    Ich kann dir sagen was schuld ist (ich hab grad nachgesehen).


    Es sind die von ServicePosition abgeleiteten Converter.
    ServicePosition ist ein Poll Converter und sorgt ggf. für genau solche Effekte.


    ServicePosition läuft in seiner momentanen Form bereits beim __init__ los...


    Schaun wir uns das doch mal an. ServicePosition macht folgendes



    Sieht erstmal unverdächtig aus.
    self.poll_interval und self.poll_enabled sind geerbte Properties aus der "Poll" class.
    ein Blick da hinein verrät:



    Ups?! Der Timer läuft also sofort im init an.
    Zwar noch nicht bei setzen von poll_interval, jedoch dann beim setzen von poll_enabled.
    Die einfachste und schönste Lösung für deinen Fall:


    Python
    def __init__(self, type):
            ServicePosition.__init__(self, type)
            self.doSuspend(1) #Stop the poll timer that ServicePosition.__init__(...) starts!


    Für alle 3 Converter (sind ja alle von ServicePosition abgeleitet)
    Ich muss mir das mal noch genau ansehen ob wir das nicht auch noch direkt im ServicePosition Converter fixen können/sollten.


    Im übrigen meine ich mich zu Erinnern, von diesem Problem schon in Verbindung mit anderen Plugins gehört zu haben.


    Nachtrag: Ich hab's jetzt nochmal angesehen und es ist eigentlich ein Bug den wir auf unsere Seite auch fixen sollten...
    Ich möchte dich aber bitten das trotzdem wie oben gezeigt zu lösen, Ich fix das dann parallel in Poll (das tut dann später nicht weh).


  • Die einfachste und schönste Lösung für deinen Fall:

    Python
    def __init__(self, type):
            ServicePosition.__init__(self, type)
            self.doSuspend(1) #Stop the poll timer that ServicePosition.__init__(...) starts!

    ...

    Perfekt, das funktioniert jetzt ohne meinen "Würgaround" mit .show() + .hide() :thumbs_up:

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • hier die aktuelle Version 1.5f :winking_face:


    Änderungen in Version 1.5f:

    • neu: beim Kanalwechsel über die Kanalliste kommt jetzt bei aktivem Timeshift eine Frage, ob man wirklich umschalten will
      (bisher konnte man in der Kanalliste problemlos umschalten, dass man da aber im aktiven Timeshift war, merkte man leider meist erst danach)
    • gefixt: nach dem Deaktivieren des PTS im Setup gab es einen GS (auch beim Boxstart, wenn das PTS im Setup nicht aktiviert war)
    • gefixt: nach Ende des Timeshiftfiles beim schnellen Vorlauf wird jetzt korrekt der normale InfoBarSummary (Display-Screen) gesetzt
    • gefixt: Converter des neuen InfoBarTimeshiftState-Screen werden jetzt nach GUI-Restart gestoppt - Dank an @Reichi :thumbs_up:
      (vorher haben diese im Hintergrund ständig Werte abgefragt, auch wenn das Timeshift gar nicht aktiv genutzt wurde)

  • Ich glaube, die letzte Version läuft jetzt stabil :winking_face:


    Von daher habe ich mal die Änderungen in einem Fork eingetragen:
    Edit: aktueller Link im Post #59


    Ich hoffe, ich hab das mit den neuen Ordnern für Converter/Source und Makefile.am richtig gemacht.


    Wäre schön, wenn da mal jemand vorher kurz drüberschauen könnte, ob das passt, bevor ich den PullRequest mache. :thumbs_up:


    Die Quelle für das PTS-Paket liegt doch hier im GitHub, oder?
    https://github.com/opendreambo…plugin-permanenttimeshift

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

    Einmal editiert, zuletzt von Sven H ()

  • Aha, Danke. :thumbs_up:


    Da muss ich dann am Ende noch für jeden neuen Ordner ein "Ordnername/Makefile" eintragen?
    Dann auch für die Unterordner?


    Components/Makefile
    Components/Converter/Makefile
    ...


    Kann ich das jetzt als neuen Commit nachtragen, oder sollte ich den Fork nochmal neu machen?

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • Verdammt, die fehlen ja auch noch :winking_face:


    Dann mach ich das nochmal ganz neu.
    Sieht sonst in den commits nicht schön aus :winking_face:

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP