yavdr ansible

seahawk1986 ,

danke für die ausführliche Auskunft.

Ich werde das Morgen testen und mich melden ob es geklappt hat.

So, ich habe das mal getestet, mit nicht ganz durchschlagendem Erfolg, aber einer Lösung die für mich geht.

Eine neue Datei softhddevice_custom.py

from .genericfrontend import SofthdBaseClass

class Softhddevice(SofthdBaseClass):
    name = 'softhddevice'


from gi.repository import GLib
from .genericfrontend import SofthdBaseClass
class Softhddevice(SofthdBaseClass):
    name = 'softhddevice'
    def start(self, options=None):
        self.set_brightness("0")
        super().start(options)
        GLib.timeout_add_seconds(1, self.set_brightness, "-40")
    def set_brightness(self, value="0"):
        code, result = self.dbus2vdr.Setup.Set("softhddevice.Brightness", value)
        return False

habe ich erstellt und die Änderung in der /etc/yavdr-frontend/config.yml habe ich wie oben beschrieben gemacht.

Prinzipiell funktioniert es und nach dem Beenden von KODI und der Rückkehr zum VDR wird der neue Wert (ich habe testweise einfach mal einen Wert von "-200" genommen, um sofort zu sehen, ob es funktioniert) in die setup.conf eingetragen, aber der Wert ist nicht aktiv! Es ist wieder der Defaultwert = 0 aktiv.

Aber bei meiner Probiererei habe ich nun festgestellt, dass man immer erst noch einen Senderwechsel ausführen muss, damit der in der setup.conf vorhandene Wert auch aktiviert wird.

Das ist also der entscheidende Punkt:

Die Werte werden nur aktiviert nach dem ein Senderwechsel gemacht wurde bzw. es funktioniert auch nach einem DETACH/ATTACH des softhddevice-Plugin über das OSD. Ab dann ist der neue Wert aktiv.

Im Prinzip kann ich damit leben, denn einen Senderwechsel macht man ja doch sehr oft und somit wäre dann der Helligkeitswert aktiv.

Was natürlich jetzt noch optimal wäre, dass das Script den manuell eingestellten Wert aus der "setup.conf" ausliest und dann verarbeitet. Also nicht einen festen Wert "-40" sondern den manuell über das Setup-OSD eingestellten Wert nimmt. Dann wäre man total variabel und könnte einfacher probieren was am besten ist!

Paul

PS: Eine 2. Möglichkeit ist dann noch, das Einstellungs-OSD öffnen und die Einstellungen für das softhddevice-Plugin aufrufen. Da sieht man dann auch den neuen Wert. Jetzt muss man den Wert oder irgendeinen anderen Wert nur mit OK bestätigen und sofort ist der neue Wert aktiv.

PPS: Das softhddevice-Plugin wird übrigens mit der Option "-D" gestartet.

Zitat von Paulaner

Aber bei meiner Probiererei habe ich nun festgestellt, dass man immer erst noch einen Senderwechsel ausführen muss, damit der in der setup.conf vorhandene Wert auch aktiviert wird.

Zitat von Paulaner

Was natürlich jetzt noch optimal wäre, dass das Script den manuell eingestellten Wert aus der "setup.conf" ausliest und dann verarbeitet.

Das kann man einbauen:

from gi.repository import GLib
from .genericfrontend import SofthdBaseClass

class Softhddevice(SofthdBaseClass):
    name = 'softhddevice'
    def start(self, options=None):
        original_brightness, *_ = self.dbus2vdr.Setup.Get("softhddevice.Brightness")
        self.dbus2vdr.Setup.Set("softhddevice.Brightness", "0")
        super().start(options)
        GLib.timeout_add_seconds(1, self.set_brightness_retune, original_brightness)

    def set_brightness_retune(self, value):
        code, result = self.dbus2vdr.Setup.Set("softhddevice.Brightness", value)
        current_channel, *_ = self.dbus2vdr.Channel.Current()
        self.dbus2vdr.Remote.SwitchChannel(current_channel)
        return False

Zitat von Paulaner

PPS: Das softhddevice-Plugin wird übrigens mit der Option "-D" gestartet.

Das ist beabsichtigt, weil der VDR dann unabhängig vom X-Server starten, das Frontend beim Start für Aufnahmen detached bleiben und man auch KODI als Frontend starten lassen kann.

@seahawk,

danke für die schnelle Antwort.

Die Änderung für die softhddevice_custom.py werde ich morgen testen, jetzt bin ich schon unterwegs und nicht mehr am VDR.

Melde mich dann morgen, ob es funktioniert hat!

Paul

seahawk1986 ,

Ich hatte jetzt etwas Zeit zum Testen und habe die neuen Codes in die die softhddevice_custom.py eingebaut.

Die Übernahme des manuell über das Setup-OSD eingestellten Wertes klappt einwandfrei.

Ich vermute mal, dass der Code in Zeile 14,15 einen Senderwechsel bzw. einen erneuten Aufruf des Senders machen soll.

Das funktioniert leider nicht, so dass der Wert doch erst nach einem "richtigen" Senderwechsel aktiv wird, oder wenn ich auf der FB den eingestellten Sender nochmals eingebe. Also wenn z.B. Sender "5" nach dem Booten eingestellt ist und ich dann nochmals "5" über die FB-Taste eingebe, dann klappt es.

Vielleicht kannst Du da nochmals schauen, ob Du eine andere Lösung findest.

Wenn nicht, dann wäre das auch nicht schlimm und ich könnte damit auch gut leben.

Paul

Zitat von Paulaner

Ich vermute mal, dass der Code in Zeile 14,15 einen Senderwechsel bzw. einen erneuten Aufruf des Senders machen soll.

Ja genau, das holt sich den aktuell eingestellten Kanal und sorgt dann dafür, dass er erneut getuned wird - auf meinem Testsystem hat das gestern so zumindest funktioniert... - vermutlich gibt es da ein Timing-Problem zwischen dem Einlesen der geänderten Setup-Einstellungen und dem Retune - probier es mal so (ggf. i Zeile 11 den Timeout etwas höher als 1 setzen):

from gi.repository import GLib
from .genericfrontend import SofthdBaseClass

class Softhddevice(SofthdBaseClass):
    name = 'softhddevice'
    def start(self, options=None):
        original_brightness, *_ = self.dbus2vdr.Setup.Get("softhddevice.Brightness")
        self.dbus2vdr.Setup.Set("softhddevice.Brightness", "0")
        super().start(options)
        self.dbus2vdr.Setup.Set("softhddevice.Brightness", original_brightness)
        GLib.timeout_add_seconds(1, self.retune)

    def retune(self):
        current_channel, *_ = self.dbus2vdr.Channel.Current()
        self.dbus2vdr.Remote.SwitchChannel(current_channel)
        return False

Hallo,

ich bin mir nicht sicher, ob das was mit yavdr ansible zu tun hat, aber unter yavdr 0.6 auf gleicher Hardware hatte ich das Problem nicht.

Lasse ich ein Video per vdr schneiden oder ich installiere per apt Softwarepakete hagelt es Artefakte im TV Bild, öffne ich das OSD stürzt der vdr auch schonmal ab.

Hardware: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz, Zotac Nvidia GT640, SSD, Digital Devices GmbH Cine V7

Wo könnte ich da mal ansetzen um dem Problem auf die Spur zu kommen?

Zitat von massi

Wo könnte ich da mal ansetzen um dem Problem auf die Spur zu kommen?

Versuch mal ein anderes vdr-plugin-softhddevice zu benutzen; zum Beispiel das mit openglosd und ffmpeg.

Ich habe auch viele Artefakte bei hoher Festplattenlast gehabt und diese dadurch behoben, dass ich im BIOS den Prozessor nicht runtertakten lasse. Wie genau die Einstellung heisst, müsste ich heute Abend nachschauen.. Seit dem ist das Problem bei mir weg, aber der PC ein wenig lauter

Bei mir trat das Problem allerdings schon bei yavdr 0.6 auf. Ist aber bei ansibler nicht wieder aufgetreten.

Gruß Micha

Zitat von seahawk1986

Ja genau, das holt sich den aktuell eingestellten Kanal und sorgt dann dafür, dass er erneut getuned wird - auf meinem Testsystem hat das gestern so zumindest funktioniert... - vermutlich gibt es da ein Timing-Problem zwischen dem Einlesen der geänderten Setup-Einstellungen und dem Retune - probier es mal so (ggf. i Zeile 11 den Timeout etwas höher als 1 setzen)

Habe ich mal getestet, den neuen Code genommen und auch den Timeout erhöht, aber irgendwie will es bei mir nicht so richtig.

Ich muss immer manuell über die FB die Kanalnummer nochmals eingeben, damit der Helligkeitswert aktiv wird.

Mal noch ne Frage, welche softhddevice-Variante nutzt Du? Ich habe softhddevice-vpp im Einsatz.

NACHTRAG:

Jetzt habe ich mal das "vdr-plugin-softhddevice-openglosd-ffmpeg-2.8" installiert und da funktioniert es, wenn ich von KODI zurück zum VDR wechsle. Da wird dann sofort der richtige Helligkeitswert aus der "setup.conf" aktiviert.

Was jetzt noch nicht geht ist bei einem Neustart des VDR, da brauchts immer noch einen Senderwechsel bzw. das nochmalige Eingeben der Sendernummer. Aber da ich nach dem Start des VDR ja sowieso meistens auf einen anderen Sender wechsle ist das für mich kein großers Problem mehr.

NACHTRAG 2 :

Jetzt habe ich ein paarmal neu gebootet, um alles zu testen und jetzt geht es wieder nicht mehr "automatisch" nach der Rückkehr von KODI zum VDR. Ich habe nichts an der Datei softhddevice_custom.py geändert und trotzdem will es nicht mehr automatisch!

Ich geb erstmal auf, denn jetzt habe ich keine Zeit mehr zum probieren.

Ich hatte gestern softhddevice-vpp mi einem zweimaligen Aufruf von frontend-dbus-send toggle (dadurch wird das Frontend erst detached und beim zweiten Aufruf wieder Attached) probiert.

Ich habe gerade noch einen Fehler gefunden (ein s im Klassennamen für Channels vergessen) - so funktioniert es bei mir auch beim Booten:

from gi.repository import GLib
from .genericfrontend import SofthdBaseClass

class Softhddevice(SofthdBaseClass):
    name = 'softhddevice'
    def atta(self, options=""):
        original_brightness, *_ = self.dbus2vdr.Setup.Get("softhddevice.Brightness")
        super().atta(options)
        self.dbus2vdr.Setup.Set("softhddevice.Brightness", "0")
        GLib.timeout_add_seconds(1, self.set_brightness_retune, original_brightness)

    def set_brightness_retune(self, value):
        code, result = self.dbus2vdr.Setup.Set("softhddevice.Brightness", value)
        current_channel, *_ = self.dbus2vdr.Channels.Current()
        self.dbus2vdr.Remote.SwitchChannel(current_channel)
        return False

Zitat von massi

Wo könnte ich da mal ansetzen um dem Problem auf die Spur zu kommen?

Hast Du schon in den Log geschaut?

Gibt es Meldungen wegen Pufferüberlauf?

Bei mir half da mal folgender Patch:

Index: vdr-2.4.0_sik/dvbdevice.c
===================================================================
--- vdr-2.4.0_sik.orig/dvbdevice.c    2019-01-20 18:12:49.766111992 +0100
+++ vdr-2.4.0_sik/dvbdevice.c    2019-01-26 21:25:20.364336216 +0100
@@ -2234,7 +2234,7 @@
   CloseDvr();
   fd_dvr = DvbOpen(DEV_DVB_DVR, adapter, frontend, O_RDONLY | O_NONBLOCK, true);
   if (fd_dvr >= 0)
-     tsBuffer = new cTSBuffer(fd_dvr, MEGABYTE(5), CardIndex() + 1);
+     tsBuffer = new cTSBuffer(fd_dvr, MEGABYTE(20), CardIndex() + 1);
   return fd_dvr >= 0;
 }

Ich habe jetzt alle softhddevice Plugins ausprobiert, das Problem bleibt.

Den Log verfolge ich noch, bisher aber keine Auffälligkeiten bzgl. des Buffers.

Zitat von zaubi4u

Wie genau die Einstellung heisst, müsste ich heute Abend nachschauen.

Das wäre nett.

Also bei meinem Intel G41 Board steht die Einstellung unter "Advanced BIOS Features" und heisst CPU EIST (Enhanced Intel SpeedStep Technology). Ist normaler Weise eingeschaltet, sollte aus sein. Bei AMD Prozessoren wäre die Entsprechung "Cool & Quiet"

Hoffe, das hilft Dir weiter.

Gruß Micha

Danke, mal sehen, ob mein altes Board diese Einstellung hat.

Mein Board ist auch nicht das allerneuste, noch mit 775-er Intel Sockel

Zitat von seahawk1986

Ich habe gerade noch einen Fehler gefunden (ein s im Klassennamen für Channels vergessen) - so funktioniert es bei mir auch beim Booten:

Bei mir funktioniert es jetzt auch! Das fehlende "s" war die Lösung!

Damit wäre mein Problem mit diesem Workaround gelöst!

Besser wäre es natürlich, wenn man die Ursache beseitigen würde, aber auch so geht es erstmal.

Danke für die schnelle und wie immer sehr kompetente Hilfe.

Paul

Zitat von zaubi4u

Also bei meinem Intel G41 Board steht die Einstellung unter "Advanced BIOS Features" und heisst CPU EIST (Enhanced Intel SpeedStep Technology). Ist normaler Weise eingeschaltet, sollte aus sein.

Das scheint tatsächlich zu funktionieren, ich habe EIST abgeschaltet und dann gleich noch "Enhanced Halt State" (C1E), keine Artefakte mehr, ich kann jetzt sogar ohne Probleme einen Film schneiden lassen und gleichzeitig noch per apt ein paar Pakete installieren, danke für den Tip!

Ich werde das Ganze noch eine Zeit beobachten um ganz sicher zu sein.

Warum mir das aber jetzt erst unter yavdr ansible aufgefallen ist, weiß der Teufel, scheint ja dann wohl nichts damit zu tun zu haben.

Bitte, gerne massi. Hab mich lange mit dem Problem rumgeschlagen und alles mögliche probiert, bis mir ein Freund sagte: beim vdr machen alle Maßnahmen zum Runtertakten der CPU im Zweifel ärger.... Ich hatte schon markad deaktiviert, weil das nicht ging und Schneiden nur, wenn keine andere Aufnahme lief.... Aber nach der BIOS Änderung war alles gut Freu mich, wenn ich helfen konnte.

Gruß Micha

Vielleicht ist ja damit auch das Problem behoben, daß ich öfter mal Aufnahmen verwerfen mußte, weil die vor lauter Artefakten nicht ansehbar waren.

Freut mich, daß Du mir geholfen hast.;)