yavdr ansible

  • Ich möchte auch noch kurz eine Rückmeldung geben.

    Auch bei mir kam es zu keinen Abstürzen mehr, seit das live-Plugin aktualisiert wurde.

  • Hier gab es bei Beendigung eines Timers doch noch einen VDR-Absturz:


    Silverstone LC 16-MR, P5N7A-VM , Cine S2 Dual DVB-S2 V5.5, E5200, 64 GB Crucial CT064M4, 2 TB WD 20EARX

  • horchi seit 2 Tage kein Crash, ich denke, das ist schon die richtige Stelle.

    Um das Problem weiter einzugrenzen habe ich den Code wie folgt geändert:

    Code
    1. bool vpsUsed1 = rr->timer->HasFlags(tfVps);
    2. bool vpsUsed2 = rr->timer->Event();
    3. bool vpsUsed3 = rr->timer->Event()->Vps();
    4. bool vpsUsed = vpsUsed1 && vpsUsed2 && vpsUsed3;

    Dann sehen wir, welche der 3 Funktionen das Problem verursacht. Ich melde mich mit dem nächsten Backtrace wieder.

  • horchi Hallo, ich habe jetzt den Backtrace von dem geänderten Code. Hilft dir das weiter ?

  • Hallo seahawk1986 ,


    bin grad wieder am Testen.

    Den Ansatz mit Ansible finde ich echt geil:welle. Vielen Dank dafür:respekt

    Ich möchte zukünftig meine VDRs von einem zentralen Rechner administrieren und nutze deshalb Dein Playbook remote.

    Da mein Hauptrechner mit Siduction (Debian Sid) läuft, sind da natürlich, durch unterschiedlichen Distris, Probleme zu erwarten.

    Ein Problem habe ich identifiziert, vielleicht kannst Du die Lösung ins GIT übernehmen.

    Die Jinja2 Templates machen aufgrund des iteritems() Probleme, Python3 kennt diese Methode nicht mehr.

    Laut Ansible kann man den Code einfach ändern. Habe ich probiert und funktioniert bei mir.

    Betroffen sind diese Dateien:

    Code
    1. 20-intel.conf.j2
    2. nfs-exports.j2
    3. smb.conf.j2

    Geändert werden sollte:

    Code
    1. iteritems()
    2. ÄNDERN IN
    3. items() | list

    Gruß

    Frank

    YaVDR-ansible , Case: HFX Classic, Mainboard: ASUS H97M-E, CPU: Intel Celeron CPU G1840T, GPU: GeForce GT 1030, DVB-S: Digital Devices Cine S2 V6

    YaVDR-ansible (24/7), Case: Akasa, Mainboard: NUC D34010WYB, DVB-S: Sundtek SkyTV Ultimate 6 2016/Q1, Miscellaneous: epgd, pihole (DoH)

    YaVDR-ansible (headless), System: HP 260 G2 DM, DVB-S: SkyTV Ultimate IV

  • Ein Problem habe ich identifiziert, vielleicht kannst Du die Lösung ins GIT übernehmen.

    Bitte sehr: https://github.com/yavdr/yavdr…3f9adca0c5a895996d886c7a0

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Perfekt, Danke. :applaus


    Noch eine Frage.

    Laut Manual.html gibt es eine einen Treiber "drivers: sundtek: auto" und eine Rolle "install-sundtek", im GIT finde ich die aber nicht.

    Wie komme ich da ran?


    Ich persönlich brauche kein HotPlug, mir würde es reichen wenn der Stick (DVB-S) standardmäßig eingebunden wird.

    Habe ich jetzt manuell gemacht, aber im playbook wäre es natürlich schöner. So was wie Rolle sundtek-static, bis es eine Lösung mit dynamite gibt.


    Gruß

    Frank

    YaVDR-ansible , Case: HFX Classic, Mainboard: ASUS H97M-E, CPU: Intel Celeron CPU G1840T, GPU: GeForce GT 1030, DVB-S: Digital Devices Cine S2 V6

    YaVDR-ansible (24/7), Case: Akasa, Mainboard: NUC D34010WYB, DVB-S: Sundtek SkyTV Ultimate 6 2016/Q1, Miscellaneous: epgd, pihole (DoH)

    YaVDR-ansible (headless), System: HP 260 G2 DM, DVB-S: SkyTV Ultimate IV

  • Momentan setze ich als Ausgabe-Plugin das "softhdcuvid" ein, weil ich ab und zu die UHD-Sender teste.

    Um die Entwicklung des Plugins ist es z. Z. etwas ruhig geworden und die Probleme mit dem PIP wurden noch nicht beseitigt. Da ich doch ab und zu das PIP des Ausgabe-Plugins einsetze, gibt es dann immer wieder gravierende Probleme das mir der VDR hängen bleibt. Dann hilft nur noch ein "harter" Reset, um den VDR wieder neu sterten zu können.


    Da das mit einem produktiven Einsatz nicht vereinbar ist, will ich jetzt erstmal wieder zum "normalen" softhddevice-Plugin wechseln.

    Aber ich weiß jetzt gar nicht, welches der 4 im ppa:experimental-vdr vorhandenen softhddevice-Plugins ich nehmen soll?

    Ich habe eine Nvidia-GT1030 im VDR und nutze das skingesigner-Plugin für das OSD.

    Welches softhddevice-Plugin soll ich dafür nehmen bzw. worin unterscheiden sich die ganzen 4 softhddevice-Plugins?


    Paul

  • Welches softhddevice-Plugin soll ich dafür nehmen bzw. worin unterscheiden sich die ganzen 4 softhddevice-Plugins?

    Wenn du 8-Bit HEVC-Material brauchst z.B. das vdr-plugin-softhddevice-vdpau-hevc (das wird gegen eine etwas ältere ffmpeg-Version gebaut, weil mit ffmpeg 3.4 die hardwarebeschleunigung für HEVC mit VDPAU nicht mehr geht), ansonsten vermutlich das vdr-plugin-softhddevice-openglosd, wenn du auf HEVC verzichten kannst, aber ein OSD mit Hardwarebeschleunigung haben willst.


    Dann bleiben noch vdr-plugin-softhddevice-vpp - das entspricht dem letzten Stand aus dem Branch von rofafor vor der Abspaltung von vaapidevice (und funktioniert mit VDPAU und VA-API, weshalb das vom Playbook vorinstalliert wird) und vdr-plugin-softhddevice-hevc, das https://github.com/jojo61/vdr-plugin-softhddevice entspricht, bei dem jojo61 mit CUVID-Decoding bei VDPAU-Ausgabe (in 8 Bit) gespielt hatte.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Aha, jetzt bin ich etwas schlauer ;)

    HEVC braucht man ja nur für UHD und DVB-T2.

    Da ich beides für einen Produktiv-VDR nicht benötige werde ich also mal "softhddevice-openglosd" nehmen und vielleicht auch "softhddevice-vpp" testen.

  • Ich hatte zuerst das "softhddevice-vpp" probiert, aber da gab es ab und zu Probleme mit einem nicht synchronen Ton. Ein paar mal hin und herschalten, dann war der Ton wieder synchron, aber das hat mich dann doch genervt.


    Dann habe ich das "softhddevice-openglosd" installiert und bin soweit zufrieden, da läuft alles richtig und es gibt auch keinen asynchronen Ton.


    Seit der Installation des "normalen" softhddevice-Plugin (egal ob -vpp oder -openglosd) an Stelle des "softhdcuvid-Plugins" bekomme ich jetzt immer im Abstand von genau 1 Minute eine Meldung in das syslog geschrieben! :|

    Das ist jetzt nicht dramatisch, aber irgendwie unschön und müllt nur das syslog zu:

    Code
    1. ...
    2. Feb 26 10:54:54 yaVDR vdr: video: 26:20:57.870 +30 403 0/\ms 66+3+4 v-buf
    3. Feb 26 10:55:54 yaVDR vdr: video: 26:21:57.870 +30 371 0/\ms 60+3+4 v-buf
    4. Feb 26 10:56:54 yaVDR vdr: video: 26:22:57.870 +30 371 0/\ms 60+3+4 v-buf
    5. Feb 26 10:57:54 yaVDR vdr: video: 26:23:57.870 +30 403 0/\ms 70+3+4 v-buf
    6. Feb 26 10:58:54 yaVDR vdr: video: 26:24:57.870 +30 371 0/\ms 67+3+4 v-buf
    7. Feb 26 10:59:54 yaVDR vdr: video: 26:25:57.870 +30 403 0/\ms 72+3+4 v-buf
    8. Feb 26 11:00:54 yaVDR vdr: video: 26:26:57.870 +30 371 0/\ms 65+3+4 v-buf
    9. ...

    Ich würde gern wissen wo das her kommt, damit ich das weg bekomme.


    Paul

  • Die Meldungen sind doch aber normal beim softhddevice. Ob man es rausfiltern kann, keine Ahnung. Wenn das genau so im Abstand von 1min kommt, läuft dein softhddevice perfekt.

    Lt. Wiki liegt ein Problem vor, wenn diese Meldungen öfter als im Abstand von 1min kommen.

  • Die Meldungen sind doch aber normal beim softhddevice.

    Okay, dann muss ich mir keine ernsthaften Sorgen machen! ;)

    Allerdings muss es da doch noch irgendwelche Möglichkeiten geben, diese Meldungen zu unterdrücken.

    Denn bei meinem anderen Produktiv-VDR, der noch mit yaVDR-0.6 und "softhddevice-???-Plugin" läuft habe ich keine solchen Meldungen im syslog.


    Bei meinem hier gemeinten Test-VDR mit yavdr-ansible habe ich jetzt allerdings diese oben beschriebenen Meldungen, aber auch nur wenn ich ein "softhddevice-???-Plugin" verwende, beim "softhdcuvid-Plugin" gibt es diese Meldungen wiederum nicht.


    Das ist wie gesagt kein Problem, sondern mehr etwas kosmetisches!

    Aber neugierig bin ich schon, wo da die Unterschiede in yavdr-0.6 und yavdr-ansible sind!

  • also ich habe die Meldungen sogar auf einem alten yavdr-0.5 und kenne die auch von meinem yavdr-0.6. das hat johns damals so in sein softhddevice eingebaut. inwieweit die vielen forks das übernommen haben, keine ahnung.

    es gibt bestimmt eine möglichkeit das im syslog zu filtern, dass die nicht geschrieben werden.

  • Etwas in dieser Art sollte diese (und andere "unschöne" Ausgaben) unterdrücken:


    Code
    1. root@htpc:/etc/rsyslog.d# cat 22-vdr.conf
    2. :msg, contains, "SVDRP htpc < " stop
    3. :msg, contains, "SVDRP htpc > " stop
    4. :msg, contains, "VNSI: Requesting clients to reload" stop
    5. :msg, contains, " v-buf" stop

    An Stelle von htpc ist natürlich der eigene Hostname einzutragen. ;-)


    Anschließend noch ein systemctl reload syslog.service absetzen.


    Man könnte natürlich auch den Default Debug Level (3) vom VDR runterschrauben,

    indem man in /etc/vdr/conf.d/00-vdr.conf ein --log 1 oder --log 2 einfügt.


    Cheers,

    Ole

    The post was edited 2 times, last by OleS ().

  • Man könnte natürlich auch den Default Debug Level (3) vom VDR runterschrauben,

    indem man in /etc/vdr/conf.d/00-vdr.conf ein --log 1 oder --log 2 einfügt.

    Yepp, genau das war/ist es. hatte ich irgendwie vergessen.

    Denn das hatte ich in yavdr-0.6 auch gemacht, einfach den Loglevel auf --log=2 gesetzt und schon ist der VDR und das softhddevice-Plugin nicht mehr so geschwätzig!


    Danke für den Tipp! :)

  • seahawk1986


    Hallo,


    Das vdr-plugin-xmltv2vdr in deinem PPA sieht die eplists nicht, da es das Verzeichnis unter dem Home Verzeichnis sucht. Könntest du vielleicht die xmltv2vdr.conf Datei mit dem richtigen Pfad versehen?

    Code
    1. [xmltv2vdr]
    2. -e /var/cache/eplists/episodes

    Und wenn du schon dabei bist, was hälst du davon auch den Ort zu verlegen, wo xmltv2vdr die Importierten EPG Daten speichert. Per default kommen sie auf die Aufnahmeplatte. Wäre es nicht sinnvoll sie nach/var/cache/vdr zu verlegen?


    MfG

  • Wenn das xmltv2vdr plugin die eplists vom vdr-addon-seriestimer sieht, erscheint im xmltv2vdr die Option, es zu aktivieren. Jedoch wenn ich es aktivere, erhalte ich Abstürze. Kann jemand es bestätigen oder ist es ein Problem lokal bei mir?


    MfG