yavdr-ansible focal auf NUC10i3 etc.

  • Ich habe mal ein dbg-Paket für epgsearch hinzugefügt: https://launchpad.net/~yavdr/+…82/+listing-archive-extra - das muss nur noch veröffentlicht werden.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • ... hier der Backtrace:

    Und bist Du nicht willig, so brauch ich Geduld!
    System: TV Philips 4k, + CEC-Remote, Octopus Net

    Odroid N2+ mit VDRSternELEC

    2 Mal editiert, zuletzt von Klemmerle ()

  • 2.Test:

    1) htop zeigt zwei PIDs bei 100%: 15183 und 15199 -- $(pidof vdr) liefert die 15183

    2) der BT liefert:

    Code
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    --Type <RET> for more, q to quit, c to continue without paging--c
    0x00007ffbf6522110 in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
    (gdb)


    bt full:


    - ich nehme allso an, dass der vdr in libpthread.so.0 in der Funktion "__lll_lock_wait ()" hängt...

    und nun ? ?(

  • Hi seahawk,

    habe mal Dein python-script für ofenheizer laufen lassen. Anbei der letzte log-Teil ab dem die Last bei 100% stehen geblieben ist.

    Die letzten beiden Kanal-Nummern (272 und 289) waren nicht verfügbare Kanäle.

    Kann ich eigentlich nicht verfügbare Kanäle automatisch entfernen lassen?


    Gruß K.


    Ich werde mal testweise die Channels.conf auf 100 Einträge einkürzen...

    Und bist Du nicht willig, so brauch ich Geduld!
    System: TV Philips 4k, + CEC-Remote, Octopus Net

    Odroid N2+ mit VDRSternELEC

  • Kann ich eigentlich nicht verfügbare Kanäle automatisch entfernen lassen?

    Wenn der VDR die als OBSOLETE markiert hat, könnte z.B. sowas helfen:

    Code: /etc/systemd/system/vdr.service.d/remove-obsolete.conf
    [Service]
    ExecStartPre=-/usr/bin/sed -i '/OBSOLETE/d' /var/lib/vdr/channels.conf

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

  • Da gibt es aus alten Zeiten noch ein Script, welches einfach nach einer einstellbaren Anzahl an Tagen die Einträge in der channels.conf, die bereits mit "OBSOLETE" markiert sind, löscht bzw. in eine eigene Datei verschiebt, und danach gleich alle noch vorhandenen Einträge ebenfalls mit "OBSOLETE" markiert.

    Die Markierung wird vom Kanaleditor im VDR nicht angezeigt.

    Jeder Channelscan (händisch oder eben vdr selbst) überschreibt die Flags, und die, welche in der eingestellten Zahl an Tagen immer noch nicht überschrieben wurden, sind wieder dran.

    Das kann natürlich nur funktionieren, wenn genügend Zeit/genügend Tuner vorhanden ist/sind, um Hintergrundscans zeitgerecht durchführen zu können, und diese auch aktiviert sind.

  • Ich antworte mal hier. Auch wenn ich es auf meinem Client bis jetzt nicht wieder beobachtet hatte.

    Scheinbar war bei mir auch ein nicht mehr vorhandener Kanal in channels.conf.

    Der war aber nicht mit OBSOLETE gekennzeichnet, sondern war nur mit .im Namen vorhanden. Lt. channelmap von epgd war das mal Zee One HD.

    Könnte also schon dasselbe Problem gewesen sein.

    Wundert mich nur, dass der Fehler auf dem server nicht auftrat und spricht dafür, dass das auf dem NUC von der Schwiegermutter nicht passierte, da die Kabel hat und ich dort nur die Kanäle drin habe, die ssie auch schaut.


    Spräche aber für einen Bug im VDR, wenn der darauf so reagiert, oder?

  • seahawk1986 das Verzeichnis "vdr.conf.d" gibt es bei mir nicht. Muß es "/etc/systemd/system/vdr.service.d" heißen?

    Ups, ja das sollte /etc/systemd/system/vdr.service.d/remove-obsolete.conf heißen

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Update:

    - Bios Update auf 0047 hochgezogen

    - Kanalliste gekürzt

    - vdr.service.d/remove-obsolete.conf erstellt


    ... hat leider nix geholfen.

    Habe jetzt die Pluginliste gekürzt, das Playbook neu laufen lassen und neu gebootet...

    Und bist Du nicht willig, so brauch ich Geduld!
    System: TV Philips 4k, + CEC-Remote, Octopus Net

    Odroid N2+ mit VDRSternELEC

  • Ich (und andere) habe ein Problem mit meinem NUC beim Herunterfahren des VDR. Es dauert in der Regel 90 Sekunden, bevor das Gerät runter fährt, während dessen ist nur das yavdr-Logo zu sehen. Per ESC-Taste kann man dann sehen, dass das System irgendeinen Stop-Job beenden will, was es dann nach 90 Sekunden aufgibt und runterfährt.


    Wenn ich aber den VDR mit der Befehlsfolge


    systemctl stop vdr && sleep 4 && poweroff


    manuell herunterfahre, ist alles ok.


    Offenbar braucht das Sytem etwas Zeit, den VDR vollständig zu beenden. Frage: Kann man den Befehl zum Herunterfahren, der bei Betätigung der Powertaste erfolg, so modifizieren, dass er gem. oben durchgeführt wird?

    Intel NUC 10 NUC10i3FNH, Digital Devices Octopus NET V2 Max M4, 1000 GB Samsung 970 Evo M.2 2280 PCIe 3.0 x4 NVMe, LG OLED 77CX9LA

    Einmal editiert, zuletzt von rkp ()

  • Ja, das geht über das SHUTDOWNCMD, das in /etc/default/vdr gesetzt wird - für Playbook wäre das die Variable vdr_shutdown_command (vgl. https://github.com/yavdr/yavdr…focal/group_vars/all#L122 ff.)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo zusammen,

    habe gestern festgestellt, daß der VDR wenn er hängt zwar eine laufende Aufnahme nicht abbricht, dafür aber auch nicht beendet, d.h. die Aufnahme wird erst gestoppt, wenn ich den VDR neu starte ("sudo reboot now")

    Anbei die letzten Meldungen von der Konsole vor dem Neustart. Vielleicht kann man da ja noch was rauslesen...

  • Ich glaube, das heißt nur, dass während deines Reboot-Versuchs noch auf /oldroot/dev geschrieben wird ("busy" - vermutlich wg. der noch laufenden Aufnahme).
    Du solltest also eher dafür sorgen, dass die Aufnahme zeitgerecht normal beendet wird (warum auch immer sie das nicht tut).

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • Moin,

    ich hab nach dem Update vorgestern wieder schwer Kummer.

    Nach dem Update auf Kernel 5.8..65 und X Komponenten hab ich den Effekt, dass softhdvaapi mit vdr gleich abstürzt, xineliboutput zeigt einmal ein Bild, das stehen bleibt, der Ton läuft weiter. Bei vlc das gleiche, Standbild und Ton läuft.

    Das gilt für Life-TV UND FÜR AUFNAHMEN. Kodi 18.9 zeigt zumindest die Aufnahmen ganz normal mit laufendem Bild.

    TV kann ich da nicht sehen, weil der vdr ohne frontend gar nicht startet.

    Auch ein booten von Kerneln wie 47 oder 58, mit denen es vorher ging, geht jetzt nicht mehr.


    Jemand ähnliche Probleme oder Idee, was ich tun könnte?


    Viele Grüße

    Frank

  • TV kann ich da nicht sehen, weil der vdr ohne frontend gar nicht startet.

    Was steht denn im Log? Wenn der VDR ohne Frontend nicht starten will, dann würde ich schauen, ob die Tuner gefunden werden (weil ein Tuner notfalls primäres Frontend werden kann, aber der VDR den Start verweigert, wenn es gar kein Device gibt).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Im Log steht nach Standardmeldung commands_merged.sh ein core dump.

    femon -H zeigt normalen Status 79%, null Fehler und der Ton läuft ja.

    Ich denke, es ist was durch ein Update der Intel-Grafik-Treiber oder Kernel passiert, da ja auch Aufnahmen vom vlc nicht abgespielt werden.

  • Musst Du auch in die 20-intel.conf "DRI" "3" eintragen, und wenn ja, hast Du das gemacht?

    Mache ich immer noch von Hand, da ich noch kein skript dafür gefunden habe...

    Und bist Du nicht willig, so brauch ich Geduld!
    System: TV Philips 4k, + CEC-Remote, Octopus Net

    Odroid N2+ mit VDRSternELEC

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!