Hi,
das Plugin dynamite wartet zur Zeit bis zum ersten Aufruf von MainThreadHook, bevor OSD Meldungen ausgegeben werden.
Kann man das anders lösen? Bzw, worauf sollte ein Plugin vor der Ausgabe der ersten OSD Meldung warten?
~Markus
Hi,
das Plugin dynamite wartet zur Zeit bis zum ersten Aufruf von MainThreadHook, bevor OSD Meldungen ausgegeben werden.
Kann man das anders lösen? Bzw, worauf sollte ein Plugin vor der Ausgabe der ersten OSD Meldung warten?
~Markus
War es jemals definiert, wann ein Plugin Meldungen senden darf? Und warum sollte ein Plugin so mit Meldungen um sich werfen?
Auf jeden Fall nicht vor dem Aufruf von cPlugin::Start().
Eventuell könnte man auch auf den ersten Aufruf von cPlugin::Housekeeping() warten.
Falls das wirklich eine kritische Info ist (wobei ich die zweite Frage von wirbel durchaus für gerechtfertigt halte), könnte ich mir auch vorstellen, eine neue Funktion cPlugin::Ready() (Name nur als Vorschlag) zu machen, die unmittelbar vor der Hauptschleife einmalig aufgerufen wird (aber nur im äußersten Notfall, falls es wirklich nicht anders geht).
Die Frage von Markus war sicherlich, wie man den Aufruf von MainThreadHook in dynamite durch neue Lösungen ersetzt.
Eine halbwegs sinnvolle Möglichkeit wäre einen Timer von 30 sec zu starten, sobald cPlugin::Start() aufgerufen wird. Nach 30 sec sind spätestens alle Plugins durch mit starten. Natürlich nicht absolut schuss-sicher. Tendenziell würde ich ja auf einen solchen Check eher ganz verzichten..
Was passiert denn, wenn ein Plugin
QuoteSkins.QueueMessage(mtInfo, *osdMsg);
zu früh aufruft?
Wird das dann einfach ignoriert (also es passiert nichts) oder gibt es Probleme (VDR bleibt stehen, stürzt ab, ...)?
Aus dem Bauch heraus würde ich sagen, dass nichts passiert.
Skins.ProcessQueuedMessages() wird erst in der Hauptschleife aufgerufen, und erst dort werden gequeuete Messages angezeigt.
> dass nichts passiert.
Dann würde ich dynamite so ändern, dass nach
OSD Meldungen ausgegeben werden (also Skins.QueueMessage() aufgerufen wird). Wenn diese Meldungen dann einfach nicht erscheinen, ist das kein Problem. Falls es doch Probleme gibt, müssen wir dafür eben eine Lösung finden.
Ich glaube sogar, dass sich andere Plugins gar nicht darum kümmern.
cPlugin::Housekeeping() wird bei mir nur nach Inactivity-Timeout aufgerufen, sonst nie (auch nicht beim normalen Runterfahren nach HITK Power).
cPlugin::Ready() würde für epgsearch und m.E. auch für alle softhddevice-Varianten reichen (bis auf X11-Ready), weil nur auf den ersten Aufruf von MainThreadHook() gewartet wird. Bei epgsearch, um sicher zu sein, dass vdr READY ist und svdrpsend funktioniert. Ich hatte schon eine konfigurierbare Zeitverzögerung eingebaut, damit nicht gleich der erste Suchtimer-Thread losläuft, aber diese Zeit nach dem Plugin::Start() laufen zu lassen, gefällt mir weniger.
Ich habe aber eine Reihe Plugins gefunden, die duch MainThreadHook() jede Sekunde eine Statusüberprüfung machen (dbus2vdr, restfulapi, web, graphtftng,...) . Dafür einen eigenen Thread laufen zu lassen, der immer wieder eine Sekunde schläft, ist auf jeden Fall Aufwand.
Don’t have an account yet? Register yourself now and be a part of our community!