Crash bei drei gleichzeitig startenden Aufnahmen

  • Ich beobachte schon seit einiger Zeit. dass sich der VDR verabschiedet, wenn drei Aufnahmen zur gleichen Zeit starten. Dachte erst "blöder Zufall"... Es ist aber doch recht regelmäßig, dass wenn drei Timer um 20:08 Uhr beginnen das Live-Bild schwarz wird und der VDR nicht mehr bedienbar ist. Dann schlägt der Watchdog zu.

    Das Log: https://www.dropbox.com/s/efsn2tl4k6l2m60/sys.log?dl=0


    Folgende Timer waren aktiv:

    Code
    1. => Laufende Timer:
    2. 9:S19.2E-133-13-127:2020-10-15:2008:2112:50:99:Navy CIS| New Orleans~Hannahs Entscheidung (S06E01):<epgsearch><channel>18 - 13th St HD</channel><searchtimer>Navy CIS: New Orleans</searchtimer><start>1602785280</start><stop>1602789120</stop><s-id>466</s-id><eventid>3137846</eventid></epgsearch><epgd><timerid>8536</timerid></epgd>
    3. 9:S19.2E-133-12-126:2020-10-15:2008:2117:50:99:Marvel's Runaways~Im Land der Träume (S03E05):<epgsearch><channel>17 - SYFY HD</channel><searchtimer>Runaways</searchtimer><start>1602785280</start><stop>1602789420</stop><s-id>693</s-id><eventid>3139564</eventid></epgsearch><epgd><timerid>8537</timerid></epgd>
    4. 9:S19.2E-133-2-147:2020-10-15:2008:2047:50:99:Single Parents~Ketchup! (S01E23):<epgsearch><channel>205 - Sky One HD</channel><searchtimer>Single Parents</searchtimer><start>1602785280</start><stop>1602787620</stop><s-id>822</s-id><eventid>3139741</eventid></epgsearch><epgd><timerid>8539</timerid></epgd>

    Mir ist klar, dass ich mit dem "Problem" alleine da stehe und ich ein Einzelfall bin. Aber vielleicht hat ja jemand ne Idee was da schief geht.


    PS: VDR hat vier Tuner und Tuner 1 und 2 sind verbunden (Device Bonding)

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • Da läuft auch naludump, epg2vdr usw. gleich mit den Aufnahmen los, und CAM-Entschlüsselung kann auch ein Problem sein, wenn gleichzeitig 2 Aufnahmen darüber starten sollen.

    Ich würde mal naludump abstellen und ggf. erst "im Nachlauf" durchführen lassen, und den watchdog länger oder abschalten.

    Das schwarze Bild mag sein, wenn gleichzeitig live-TV geguckt wird und der entspr. Tuner doch von einer Aufnahme "geklaut" wird, insbes. mit dem Bonding könnte das passieren (Tuner 1 live, 2 startet Aufnahme, aber auf anderer Pol-/Band-Ebene, 1 wird "finster").

    Wie ist die Auslastung des RAM, wieviel braucht mysql?

    --
    vdr User #2022 - hdvdr2: Lenovo SFF M83, Intel(R) Core(TM) i5-4670S, 14 GB Ram, zram-swap/tmp, ubuntu-focal, softhddevice-vdpau
    ddbridge-6.x mit 2xDVB-S2 und (Flex) 2xDVB-C/T Tunern, nvidia-GF1050Ti SFF (nvidia-dkms-470), System SSD btrfs,

    snapper, 8TB HDD XFS/cow /srv/vdr, yavdr-ansible-2.5.6-seahawk, vdr-epg-daemon mit Frodo-plugins, Kernel 5.14.14-xfsscrub

    vdradmin-am, live+webstreaming, vdrmanager (Smartphones als FB), ffmpeg-4.3.1-libfdk_aac, vdr-plugin-hbbtv.

  • Zwei oder drei Aufnahmen sind kein Problem. Ich habe auch schon am fünf am laufen!

    Im Log sieht man, dass der dritte Timer nicht gestartet wird. Vermutlich da wo das Bild schwarz wird und der VDR nicht mehr reagiert.

    Das "Problem" tritt auch immer nur auf wenn der Startzeitpunkt bei dreien gleich ist.


    RAM und MySQL sollten nicht das Problem sein.


    Hier mal das ganze Logpaket: https://www.dropbox.com/s/ey35…_log_10152008.tar.xz?dl=0

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • Gestern Abend wieder:


    - Drei Aufnahmen liefen bereits. Start: 1 x 20:07 Uhr, 2 x 20:08 Uhr

    - LiveTV lief (n-tv)

    - 20:10 Uhr: Bildschirm wird schwarz, als VDR das LiveTV-Device umschalten will zur Aufnahme nr 4 (20:10 Uhr)

    - Ab dem Zeitpunkr reagiert der VDR schon nicht mehr auf die FB

    - 30 bis 60 Sekunden Später Absturz und Neustart des VDR.


    Es muss wohl irgendwas mit dem Locking der Timer zu tun haben:


    Das ganze Logpaket: https://www.dropbox.com/s/7979…_log_01142010.tar.xz?dl=1

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

    The post was edited 1 time, last by MegaV0lt: Doppelten Link entfernt ().

  • Hast Du auch markad aktiv?

    Ein ähnliches Problem hatte ich auch. Bei mir hatte ich nach langer Suche festgestellt, dass markad mit automatischer Logoerzeugung (--autologo=2) zum Crash führte. Erst bei --autologo=1 trat dieses Verhalten nicht mehr auf.

  • markad habe ich am laufen, den Fehler habe ich aber schon länger; auch schon vor dem neuen markad.

    Der VDR hängt sich ja anscheinend genau zum Umschaltzeitpunkt auf. Im Log sieht amn da kein markad starten. Auch das Umschalten wird nicht mehr geloggt...


    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • ei mir hatte ich nach langer Suche festgestellt, dass markad mit automatischer Logoerzeugung (--autologo=2) zum Crash führte. Erst bei --autologo=1 trat dieses Verhalten nicht mehr auf.

    Auch --autologo=1 macht eine automatische Logoerzeugung, aber mit weniger Speicherverbrauch. Die Variante hatte ich extra gebaut, damit es auf Systemen mit wenig Speicher (ich hatte es damals auf einem Pi1 mit 512 MB erfolgreich getestet) auch läuft. Das wäre dann ein sicherer Hinweis, dass dir der Speicher ausgeht. Wieviel Speicher und Swap hast du denn ?

    Die eigentliche Funktion von Markad läuft nicht im Plugin innerhalb VDR, sondern in einem eigenen Programm. Das Plugin startet nur das Programm. Somit kann Markad nicht den VDR abschießen (genau das war ja das Ziel dieser Aufteilung), außer: Der Speicher vom System ist komplett verbraucht.

    VDR
  • Sorry MegaV0lt fürs kapern ;-)


    Hallo kfb77,

    im meinem Server sind 8 GB RAM und 4GB Swapfile vorhanden. Der Proz ist ein I5 5th Generation. Also eigentlich genug Power/Resourcen.

    Der emergency exit vom VDR passierte meist dann, wenn >2 Aufnahmen zeitgleich stattfinden und wenigstens eine davon auf einem Kanal ohne vorhandenes Logo stattfand. Dabei handelt es sich um verschlüsselte Kanäle in HD

    Das Plugin ist auf "während" eingestellt, da ich meist im Timeshift schaue und die Marks gerne nutze.

    Nach einem emergency exit des VDR wurde alles noch schlimmer, da die Aufnahmen immer wieder neu gestartet wurden und jedes mal markad mitgespielt hat ;-)

    Jetzt mit --autologo=1 klappts mit den Aufnahmen (können auch schon mal 5 parallel sein) Für mich ist das so erstmal ok, auch wenn eine schnellere marks Erstellung bei Timeshift schon besser wäre.

    Gerne können wir auf dem markad treath weitermachen.

  • kls

    Vielleicht ne Idee?

    Crash bei drei gleichzeitig startenden Aufnahmen


    Passiert, wenn das letzte Device das noch frei ist umgeschaltet werden soll. (Meiner Meinung nach)

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • Hmm. Gäbe es eine Möglichkeit, daß in solchen Fällen Live-TV nicht durch eine Autotimer-Aufnahme unterbrochen werden kann, bzw. das Live-TV-Device, wenn softhddevice attached ist, den Tuner als "belegt" markiert oder zumindest eine OSD-Meldung erscheint, mit Abfrage, ob umgeschaltet werden soll?

    --
    vdr User #2022 - hdvdr2: Lenovo SFF M83, Intel(R) Core(TM) i5-4670S, 14 GB Ram, zram-swap/tmp, ubuntu-focal, softhddevice-vdpau
    ddbridge-6.x mit 2xDVB-S2 und (Flex) 2xDVB-C/T Tunern, nvidia-GF1050Ti SFF (nvidia-dkms-470), System SSD btrfs,

    snapper, 8TB HDD XFS/cow /srv/vdr, yavdr-ansible-2.5.6-seahawk, vdr-epg-daemon mit Frodo-plugins, Kernel 5.14.14-xfsscrub

    vdradmin-am, live+webstreaming, vdrmanager (Smartphones als FB), ffmpeg-4.3.1-libfdk_aac, vdr-plugin-hbbtv.

  • Ich denke Aufnahmen haben Priorität! LiveTV geht halt nur auf Transpondern, die von den Aufnehmenden Tunern belegt sind.

    Eine Abfrage wäre kontraproduktiv, da man ja nicht immer davor sitzt.


    Ich möchte sogar, dass der VDR das LiveTV Device ungefragt umschaltet, wenn alle anderen belegt sind. Nur so macht das doch sinn

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • Für manuell erstellte Timer, ja. Auto-Timer (epgsearch etc.) nicht unbedingt, da sollte Live-TV zumindest standardmäßig eine höhere Priorität haben. Bei Bedarf läßt sich die Priorität der Autotimer ja anpassen.

    --
    vdr User #2022 - hdvdr2: Lenovo SFF M83, Intel(R) Core(TM) i5-4670S, 14 GB Ram, zram-swap/tmp, ubuntu-focal, softhddevice-vdpau
    ddbridge-6.x mit 2xDVB-S2 und (Flex) 2xDVB-C/T Tunern, nvidia-GF1050Ti SFF (nvidia-dkms-470), System SSD btrfs,

    snapper, 8TB HDD XFS/cow /srv/vdr, yavdr-ansible-2.5.6-seahawk, vdr-epg-daemon mit Frodo-plugins, Kernel 5.14.14-xfsscrub

    vdradmin-am, live+webstreaming, vdrmanager (Smartphones als FB), ffmpeg-4.3.1-libfdk_aac, vdr-plugin-hbbtv.

  • Bei 200+ Timern bei epgsearch recht mühselig


    Hat aber nichts mit dem Problem zu tun:

    1. Jan 14 20:09:51 vdr01 vdr[16063]: epg2vdr: Updating table timers done

    2. >>> LiveTV bis hier (20:10)
    3. >>> Timer (Nr. 4) auf ZDF_neo soll starten (20:10)
    4. >>> Umschalten erfolgt nicht. Bild wird schwarz und der VDR hängt bis später der Watchdog zuschlägt

    5. Jan 14 20:10:00 vdr01 vdr[16063]: audio/alsa: using pass-through device 'hw:NVidia,7'
    6. Jan 14 20:10:00 vdr01 vdr[16063]: audio/alsa: start delay 336ms
    7. Jan 14 20:10:01 vdr01 cron[18994]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
    8. Jan 14 20:10:30 vdr01 vdr[16063]: [16063] PANIC: watchdog timer expired - exiting!
    9. Jan 14 20:10:30 vdr01 vdr[16063]: [16063] ERROR: cStateKey::~cStateKey() called without releasing the lock first (tid=16063, lock=1 Timers, key=0x55c92c8bca20)
    10. Jan 14 20:10:30 vdr01 vdr[16063]: [16063] ABORT!

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • Inzwischen hab ich die Dist gewechselt von Gen2VDR auf yaVDR. Das gleiche Problem hatte ich gestern wieder.


    Dev 0 LiveTV (verschlüsstelt)
    Drei Timer starten Gleichzeitig.

    Folge: Schwarzes Bild und VDR hängt komplett und musste resettet werden.

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • Noch eine kleine Info, die ich aus dem markad Log dabei sehen kann:

    Jede Aufnahme, die tatsächlich startet, erzeugt:

    Code
    1. markad: cStatusMarkAd::Start(): executing "/usr/bin"/markad -v -I -R --autologo=2 -l "/var/lib/markad" --online=2 before "/video/Pandora/Ein_Herz_kann_man_nicht_>

    Die gibt es aber nur von einer Aufnahme, also knallt es schon beim Start der 2. Aufnahme.

    VDR
  • Anhand des Logs ist mir nicht völlig klar, was da alles passiert - kannst du mal ein ungekürztes Log posten (journalctl -b -l bzw. für einen Zeitraum von mindestens 5 Minuten um die Aufnahme herum) und zeigen, was die Skripte machen, die um die Aufnahmen herum ausgeführt werden?


    Generell würde ich da erst mal Komplexität rausnehmen und mich dann hocharbeiten - also alle nicht essentiellen Skripte und Plugins (außer das Zeug fürs CAM, dbus2vdr und das Ausgabeplugin) deaktivieren (insbesondere epgd/epg2vdr/scraper2vdr und epgsearch) und den Watchdog deaktivieren und dann mal schauen, ob man da mit vielen parallelen Aufnahmen und Umschalten das Problem reproduzieren kann - wenn der VDR hängt mit installierten Debug-Symbolen (vdr-dbg und dbg-Pakete für die Plugins) mit gdb an den VDR Prozess hängen, ein SIGSTOP senden und schauen, was er gerade in den einzelnen Threads macht.

    Jul 08 20:08:46 vdr01 vdr[1432]: [1432] PANIC: watchdog timer expired - exiting!

    Auf welche Zeit ist der Watchdog bei dir aktuell eingestellt? Bei yaVDR ist der nicht standardmäßig aktiv, weil es mir im Zweifelsfall lieber ist, dass der Thread für eine Aufnahme weiterläuft als unterbrochene Aufnahmen zu haben.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das kenne ich doch irgendwoher...

    Habe den VDSB Neustart deaktiviert und den Watchdog auf 300s gesetzt. Das reicht in der Regel, bis epgsearch, epg2vdr, scraper2vdr und der vdr mit dem Streit um das Aufnahmen-Lock durch sind.


    Alternativ Aufnamestart bei manuell erzeugten Timer auf +/- 1 Min legen.


    Stefan

  • Die Timeoutsettings sind es vermutlich nicht, da der VDR ja komplett hängt, schwarzes Bild hat und nicht bedienbar ist.


    Das mit den +-1 Min. hab ich auch gemacht, Nur manchmal vergisst man es, bzw. bin ich ja auch nicht immer vor Ort...

    Der watchdog steht auf 30 Sekunden. Wenn der Zuschlägt, ist der VDR aber auch schon 30 Sekunden "Tot"

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004