EPG Now/Next aus EPG-Cache lesen

  • Ich streame viele Sender per rtsp von meiner Server-Box zu meiner Client-Box. Da der rtsp-Stream keine EPG-Daten enthält, lasse ich die epg.db von meiner Server-Box jeden morgen auf die Client-Box kopieren. Allerdings habe ich dort das Problem, dass die Now/Next EPG-Anzeige in der Infobar bei Sendungswechsel nicht aktualisiert wird, sondern immer die Sendung, die beim Kanalwechsel lief, als "aktuell" angezeigt. Erst wenn ich hin und her zappe, wird wieder die gerade laufende Sendung angezeigt. Es wäre super, wenn die Now/Next-Infos zeitbasiert aktualisiert werden könnten bzw. die Daten aus dem EPG-Cache benutzt werden, wenn keine Now/Next-Informationen im aktuellen Stream vorhanden sind.

  • Ich denke da wirst du dir selbst helfen müsen.


    Schau in die InfoBarGeneics.py da gibt es __evEventInfoChanged(self) welches nur auseglöst wird wenn der EPG Event feuert. Da müsstest du dir die Endzeit des aktuellen Events holen und einen Timer starten der es zu diesem Zeitpunkt wieder aufruft. Wenn dann dabei getNowNext (wieder) nichts liefert sollte es wieder die Daten aus dem Cache holen - wie das geht siehst du in der methode gleich danach, also openEventVew.

  • Irgendwie möchte das nicht so recht. Timer setzen und Funktion wieder aufrufen ist kein Problem und passiert auch zur richtigen Zeit. Ich kann auch epglist mit den richtigen Sendungen befüllen (was aber glaube ich eh unnötig ist, denn epglist ist ja beim Kanalwechsel auch leer - und trotzdem wird die aktuelle und folgende Sendung aus dem EPG-Cache dargestellt - daher wieder auskommentiert, ändert sowieso nichts):


    Eigentlich muss nur bei "magic happens here" die Infobar aktualisiert werden und die aktuelle/folgende Sendung neu einlesen. Ich komme nur nicht drauf, wie ich das anstoßen soll.


    Darüberhinaus würde ich gerne zusätzlich die InfoBar für 5 Sekunden (oder was auch immer in der Config steht) anzeigen. Dazu wäre es wohl klug einfach __eventInfoChanged aus InfoBar.py aufzurufen. Wenn ich das allerdings versuche, erhalte ich "AttributeError: type object 'InfoBar' has no attribute '_InfoBarEPG__eventInfoChanged'". Mir ist klar, was das im Grunde bedeutet und warum das passiert, komme aber eher von C/C++ und PHP und habe so gut wie keine Erfahrung mit Python und würde mich freuen, wenn Du mir kurz sagen könntest, wie ich die Funktion *korrekt* aufrufe.

  • du musst nur den gleichen code nehmen der beim infobar anzeigen wenn die epglist leer ist aus dem cache liest.

  • Genau, nur finde ich die Stelle nicht, die auch die Anzeige in der Infobar aktualisiert. Wie gesagt, ich kann die epglist befüllen - das mache ich analog zu openEventView(). Ich kann mir auch danach das EventView öffnen und dort werden Infos angezeigt. Der Sendungsfortschrittsbalken wird ebenfalls aktualsiert. Lediglich die Darstellung der aktuellen/folgenden Sendung in der InfoBar springt nicht um.
    Entweder stelle ich mich gerade blöd an und sehe den Wald vor lauter Bäumen nicht - oder es fehlt einfach noch irgendein Call, der nicht in __evEventInfoChanged und openEventView enthalten ist. An anderer Stelle habe ich auch nichts passendes gefunden und bin etwas ratlos, wo ich weiter suchen kann. Eine Idee?

  • schau in die skin.xml da Siehst du den Renderer für die InfoBar fuer die ganzen sachen wie start, endzeit und eben auch den epg.

    • Offizieller Beitrag

    Hmm /usr/lib/python/Components/Sources/EventInfo.py wäre die Datei wo du schauen solltest.


    Aber eigentlich gibt es dort schon einen Fallback auf den Epgcache wenn kein normales now/next gefunden wird.


    Am besten baust du dort mal ein paar print ein und schaust mal was dabei so raus kommt.


    cu

  • er soll ja von dort den fallback code in seinen check timer klauen :smiling_face:

  • Irgendwo ist immer noch ein nicht offensichtlicher Fehler drin. :thinking_face:


    Die skin.xml verweist auf session.Event_Now. Das wird lediglich in SessionGlobals.py gesetzt und verweist auf EventInfo. Ich dachte anfangs, dass dort eventuell irgendetwas nicht korrekt aktualisiert wird und habe mir mal Test-Ausgaben eingebaut:




    Wie man sieht, gebe ich den Inhalt von Event_Now schon einmal aus, bevor ich irgendetwas daran ändere. (Zeile 33 des Diffs).


    Wenn man sich aber mal das Log anschaut:




    ... sieht man, dass das Event bereits in beim Aufruf meines Timers in (ab Zeile 53 im Log) richtig ist. Trotzdem zeigt die Infobar immer noch die alten Sendungsnamen und Zeiten für Now/Next an. Wo kann es hier noch hängen??


    Danke für die Unterstützung :smiling_face:

  • Der Sinn des ganzen war, dass ich nicht verstanden habe, warum in der Infobar immer noch dir alten Daten angezeigt werden, obwohl EventInfo.getEvent das richtige Event zurückliefern würde. Ich ging davon aus, dass da vielleicht irgendwas gecached ist (schließlich ist auch getEvent mit @cached versehen) und wollte einfach mal das Objekt neu initialisieren. Wenn der Skin aber eh das original Objekt weiter benutzt, hat das natürlich keinen Sinn.
    Komisch ist, dass nur beim Senderwechsel getEvent für NEXT aufgerufen wird. Danach nie wieder. Es kommen nur Anfragen für NOW rein. Auch beim Öffnen der Infobar.
    Das Verhalten aber auch das selbe, wenn ich "@cached" entferne.


    Und das kann ich mir nicht erklären. So wie ich den Code verstehe, ist in session.Event_Now ein EventInfo-Objekt enthalten, das jeweils die aktuelle Sendung zurück geben müsste. Da ist eigentlich gar kein Timer meinerseits nötig, um irgendetwas zu aktualisieren, weil getEvent(0) immer korrekt die aktuelle Sendung auslesen müsste - und tut es laut Log ja auch, wenn es aufgerufen wird. Es wird aber trotzdem nicht in der Infobar angezeigt - und getEvent(1) für NEXT wird gar nicht erst erneut aufgerufen.. ????

  • bitte versuch endlich zu verstehen das bei einem transkodierten sender keine epg events kommen sondern nur durch den ersten kanalwechsel auch immer ein erster pseudo epg event erzeugt wird damit der epg code sofort durchlaufen wird und nicht erst beim naechsten sendungswechsel. Da ist auch schon fallback code drinnen der wenn kein now next da ist halt aus dem eog cache liest. Wenn du daher moeglichst wenig code verbiegen willst, war mein vorschlag diesen zapevent selbst mit einem timer zu simulieren, um eben moeglichst wenig code ueberschreiben zu muessen.


    Du musst dich aber natuerlich nicht an meine Empfehlung halten...aber du machst dir das leben unnötig schwer, was du willst ist mit einer halben codeseite zu erreichen, wenn du bestehenden code verwendest, auch ohne den zu kopieren.


    nachdem du aber die events die aus dem c++ core kommen nicht direkt ausloesen kannst musst du so wie Ghost dir gesagt hat mit prints nur rausfinden welche methoden dadurch aufgerufen werden, und mit welchen parametern und dann kannst du sie von deinem sendungsende timer aufrufen und damit den neue sendung epg event simulieren und durch den fallback code den neuen epg lesen lassen.

    Einmal editiert, zuletzt von Lost in Translation ()

    • Offizieller Beitrag

    Ja wie Gutemine schon schreibt... das Problem ist, dass es kein echtes now/next gibt... und dann bekommt e2 nicht mit wenn ein neuer event beginnt.

    Wäre eine mögliche Variante.


    cu

  • @gutemine: Dass bei transkodierten Sendern keine EPG-Events kommen, brauche ich nicht versuchen zu verstehen. Das habe ich längst verstanden - ist ja auch logisch, dass da nichts kommt. Dass ich da per Timer irgendetwas auslösen muss, habe ich auch gar nicht in Frage gestellt und wollte Deinen Vorschlag in keiner Weise bezweifeln. Ich habe lediglich gesagt, dass ich anhand dessen, wie ich den Code verstehe, gar nicht erkennne, WARUM Now/Next in der InfoBar keine aktualisierten Daten anzeigt, obwohl die EventInfo-Objekte, auf die der Skin verweist, laut Log bei einem Aufruf von getEvent() bereits korrekte Events zurückliefern. Wenn bei Anzeige der Infobar jedes mal das source Objekt bzw. die Converter abgefragt werden würden, dann würden hier bereits automatisch die aktualisierten Daten erscheinen. Hier fehlt mir das Verständnis dafür, weshalb und wo genau dem Skin bzw. Renderer klar gemacht wird, dass er das Widget bzw. den Inhalt, den die Converter bereitstellen, erneut aufgerufen muss.


    @Ghost: Danke! Das werde ich heute Abend oder morgen testen können. Warum die Daten in der Infobar nicht vorher schon aktualisiert wurden, habe ich zwar immer noch nicht genau verstanden (siehe Text an gutemine oben), aber das liegt wohl an meinem bisher eher beschränkten Einblick in die Funktionsweise von enigma2.


    Wahrscheinlich übersehe ich einfach irgendwas oder es passiert einfach im nicht einsehbaren Core. Trotzdem würde ich gern die Logik dahinter verstehen. Mir ist nämlich nicht ersichtlich, was genau passiert, wenn gotEvent(iPlayableService.evUpdatedEventInfo) aufgerufen wird und WARUM dann die InfoBar auf einmal die Events neu ausliest bzw. WO genau die Info zur Aktualisierung abgelegt wird.

    • Offizieller Beitrag

    Das ganze Source/Converter/Renderer Skin System ist event basierend. Sprich es passiert immer nur etwas, wenn ein "Ereignis" eintritt.


    Die Infobar wird ja nicht jedesmal neu gebaut, wenn du ok drückst oder sie angezeigt werden soll.


    Damit beim umschalten / anzeigen nicht alles so langsam ist werden halt die Werte immer nur neu eingelesen wenn sie sich auch ändern.


    Und das passiert halt im Falle von der EventInfo Source beim Start/Stop und beim UpdatedEventInfo Event.


    Und letzteres kommt bei Dir halt nie. Logischerweise, weil es kein Now/Next gibt.


    Der Timer sorgt nun dafür, dass halt quasi alle 60 Sekunden aktualisiert wird.


    cu

  • Ich habe noch ein wenig rumgebastelt, da mir nicht gefallen hat, dass beim Programmwechsel die InfoBar nicht automatisch angezeigt wurde und darüberhinaus alle 60 Sekunden die Events unnötig geupdated wurden.


    Inzwischen habe ich es so laufen, dass ein Timer genau passend gesetzt wird, sobald man auf einen Kanal schaltet, der zwar EPG, aber keine Now/Next-Infos hat. Die InfoBar wird ebenfalls angezeigt, sollte das in der Config aktiviert sein.


    Vielen Dank für die Unterstützung und Schubser in die richtige Richtung :smiling_face:


    Es wäre super, wenn das so, oder so ähnlich, übernommen werden kann:


    Ich schreibe das übrigens auch gern nochmal um, falls der Timer in @Ghost' Augen nicht in die InfoBar.py gehört und __eventInfoChanged besser von außen getriggert werden sollte.

    Einmal editiert, zuletzt von maluhi ()