yavdr ansible

  • seahawk1986 ,

    danke für die ausführliche Auskunft. :thumbup:

    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

    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.

  • 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.

    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:

    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.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    The post was edited 1 time, last by seahawk1986 ().

  • @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. :thumbup:


    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

  • 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):

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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?

  • 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

  • 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. :thumbup:

    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.

    The post was edited 3 times, last by Paulaner ().

  • 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:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • 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:

    VDR1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 18.04, VDR 2.4x
    VDR2: ASUS P4B533, Celeron 2.4G, FF 1.5, Ubuntu 10.10, VDR 1.6 (SS2 Rev 2.6B)
    VDR Server: sheeva-plug

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

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


    zaubi4u wrote:

    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

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

  • 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. :thumbup:


    Paul

  • zaubi4u wrote:

    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