VDR-Last geht auf 100%

  • Wegen dem Fehler in diesem Thread Core temperature above threshold, cpu clock throttled

    habe ich mal den Scaler runter gedreht.

    Nun war laut sensors die Temperatur etwas niedriger (um die 50°C) und der Logeintrag verschwand. Warum auch immer, vor der Neuinstallation lief es ja.

    Jetzt habe ich aber festgestellt, dass der VDR irgendwann nicht mehr auf FB reagiert. htop zeigt immer einen Kern (von 4) bei 100% an und sensors bei core 0: 93°C,

    Keine Ahnung wo das her kommt.

    Nach einem VDR-Neustart ist die Las wieder niedrig und sensors zeigt für beide core 50°C.


    Jemand nen Tipp. Was da plötzlich los sein kann?

  • Was nutzt du denn alles an Plugins (und ggf. Sachen wie epgd, Datenbank usw.) auf dem System?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Einzig der epgd its dazu gekommen nach der Neuinstallation. Der Rest ist identisch.

    Aber das Log sagt gar nicht, vdr läuft wunderbar weiter (schaue gerade Aufnahme), nur bedienen geht nicht mehr und eben die beschriebenen Symptome.

    Der Lüfter vom NUC dreht auch nicht hoch und wenn ich die Hand auflege, ist er nicht wärmer als vorher.

    Als ob sensors falsche werte liefert.

    Kille ich den vdr ist die Core-Temp auch sofort wieder auf 45-50°C.


    Was ich auch ungewöhnlich finde, dass wenn ich den vdr mit kill -9 PID beende, die PID im Gegensatz zu früher jetzt immer 5stellig ist.

    Einmal editiert, zuletzt von ofenheizer ()

  • So, ich muss das Thema nochmal hoch holen, da es inzwischen wieder passiert, dass die Last vom VDR plötzlich hoch geht.

    Lt. top auf 100%

    VDR-Bild und Ton laufen ganz normal weiter nur bedienen lässt sich der VDR nicht mehr per Fernbedienung. Ich kann den VDR auch nur killen.

    Kann man denn rausbekommen, was die Last plötzlich so hochtreibt? Kann das an einem Plugin liegen?


    Das Problem hatte ich ja vor der Neuinstallation nicht. Und die Plugins sind dieselben.

  • Vor ca. 1/2 Jahr hatte ein epgd-Plugin - ich glaube epg2vdr - kurzzeitig ein Memoryleak, das nach kurzer Zeit zur Unbedienbarkeit führte.

    Nicht, dass du zufällig genau diese korrupte Version nutzt?


    Bei meinem yaVDR treibt der epgd mit mariadb die CPU-Auslastung auch regelmässig arg in die Höhe - bis hin zu Rucklern und leichten Hängern beim Umschalten oder beim Ton, aber nie bis zu Unbedienbarkeit bzw. Killen-Müssen.

    Viel Erfolg!

    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

  • Ich habe bei meinem Test-VDR(Asrock) vdr-plugin-epg2vdr installiert.

    CPU Auslastung liegt ca bei 6-8%.

    CPU-Core-Temperatur bei ca 55Grad

    Alles im grünen Bereich

    VDR-1:Steacom-ST-FC9S,Steacom-ST-Nano160,Asus Prime B560M-A,Core i5-11400,NVIDIA T600,DDR4 8GB 3200MHz,Crucial P2 CT500P2SSD8 500GB,DD Cine-S2-V7,STM32 USB Adapter,CSL 300Mbit WLan-Stick,yaVDR-ansible(jammy) alle Updates.

    Client1: Raspberry Pi 3,LibreELEC 9.2.8

    Client2:Raspberry Pi 4,LibreELEC 10.0.3

    TV =Sony KD-55AF8

    Audio=Denon AVR-X2700H/Teufel-Ultima-40 5.1

  • Danke. Das hilft mir leider alles nicht.

    EPGD läuft auf dem Server. Ein Ruckeln hatte ich nie und die Plugins sind alle aktuell aus den yavdr@ansible-Quellen von seahawk.


    Das Log ist ja auch völlig unauffällig und Bild und Ton laufen ganz normal weiter. Tritt auch nicht immer auf und merke ich nur, wenn die FB nicht mehr reagiert. TOP zeigt dann für den VDR-Prozess permanten 100% an.


    Daher ja die Frage, ob man irgendwie an detailiertere Anzeigen kommt, was genau beim VDR-Prozess diese Last urplötzlich erzeugt?

  • Wann genau beginnt denn diese Lastspitze? Passiert das direkt beim bzw. nach dem Kanalwechsel oder wie muss man sich das vorstellen? In yavdr-ansible focal auf NUC10i3 etc. ff. geht es wenn ich das richtig verstehe um ein ähnliches Symptom (da habe ich auch beschrieben, wie man sich mit gdb an den VDR hängen kann, um zu sehen, was er gerade macht).


    Aus dem Backtrace, den Klemmerle gepostet hat, könnte das ein Locking-Problem beim Umschalten sein (und ihr nutzt beide satip, wenn ich das richtig sehe), aber ich hatte noch keine Zeit mir das genauer anzusehen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Kann ich nicht genau sagen. Gestern Abend lief der VDR etwa 1h im Live-TV (das erst HD & rbb HD). Danach haben wir eine Aufnahme angesehen. Nach vllt. 20min oder so, wollte ich Pause drücken und es reagierte nicht. Dann habe ich per SSH auf dem VDR nachgesehen.

    Aber das ist auch total unregelmässig. Zuletzte hatte ich es bestimmt 2-3 Tage nicht wahrnehmen können.


    Was mich eben wundert, dass es zuvor (bevor ich neu installiert habe) dieses Probelm nicht gab und der VDR der Schwiegermutti keine Probleme hat. Der ist exakt baugleich - einzige Hardwareunterschiede sind, dass ich SATIP benutze und sie Kabel-USB-Empfänger dran hat, bei mir steckt ein FLIRC als FB-Empfänger, sie hat einen USB-MCE-Empfänger. Zusätzlich werkelt in ihrem NUC noch eine 2TB HDD, bei mir liegen die Aufnahmen auf dem Server.

    Plugintechnisch ist auch alles gleich bis auf vdr-plugin-satip bei mir und sie hat sogar noch den EPGD auf dem NUC laufen.


    Ich schau mal in den anderen Thread und versuche auch mal einen BT zu bekommen.


    EDIT: Wenn ich systemd-coredump installieren möchte, bekomme ich folgendes

    Code
    Die folgenden Pakete werden ENTFERNT:
      apport ubuntu-server

    Kann doch nicht richtig sein, oder?

    Einmal editiert, zuletzt von ofenheizer ()

  • Nach vllt. 20min oder so, wollte ich Pause drücken und es reagierte nicht. Dann habe ich per SSH auf dem VDR nachgesehen.

    Aber das ist auch total unregelmässig. Zuletzte hatte ich es bestimmt 2-3 Tage nicht wahrnehmen können.

    Wenn das Ausgabeplugin den Tuner nicht belegt, macht der VDR einen EPG-Scan - da könnte ein seltener Lockingfehler beim Umschalten eher auffallen, wenn dann sehr viele Kanalwechsel in kurzer Zeit erfolgen.


    Man könnte sich mal an die dbus2vdr-Signale hängen und schauen, ob da eine hohe Last bevorzugt nach schnellen Abfolgen von Kanalwechseln auftaucht:

    Das Skript schreibt eine Logdatei nach /tmp/channelswitch.log (wenn man einen anderen Ort möchte, kann man den als Argument angeben), und loggt mit Zeitstempel, wenn der VDR umschaltet und schaut im Sekundenabstand, ob die CPU-Last auf einem Kern über 50% liegt und loggt das in dem Fall. Damit müsste man das leichter mit den Logdateien von VDR usw. korrelieren können, wann das Problem genau aufgetreten ist.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ach ja - kannst du ausschließen, dass deine Kanalliste Einträge für in der Zwischenzeit abgeschaltete Sender enthält?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ach ja - kannst du ausschließen, dass deine Kanalliste Einträge für in der Zwischenzeit abgeschaltete Sender enthält?

    Muss ich mal schauen. Räume eigentlich immer mal wieder die Kanalliste auf. Der Server hat exakt dieselbe Kanallliste.

  • Ach ja - kannst du ausschließen, dass deine Kanalliste Einträge für in der Zwischenzeit abgeschaltete Sender enthält?

    Ich habe hier die 100% bei abgeschalteten Sendern. Wodurch werden die 100% verursacht?

  • Ich habe hier die 100% bei abgeschalteten Sendern. Wodurch werden die 100% verursacht?

    Das kann ich dir leider nicht sagen, die Frage hat sich mir erst gestellt, nachdem ich deinen Post im anderen Thread gelesen hatte ...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo seahawk1986

    ich habe Dein experimental ppa vor einer Woche hinzugefügt.


    Nach dem heutigen update habe ich kein Bild mehr. Ist da eine Baustelle und soll ich zurück auf die stable oder kann man den Fehler einkreisen?

    Der VDR läuft und Aufnahmen kann ich vom Laptop aus (über VDR-LIVE) abspielen.


    Nach einem Reboot erscheint das Yavdr-Logo - aber nur mit zwei weißen Punkten und bleibt da stehen...


    Beim Versions-Check des vdr-plugin-satip ist nur die 2.4 installiert - müßte da dann auch die 2.5.2 erscheinen? Aber es lief ja bis gestern auch so...



    Ich habe hier mal einen Log-Ausschnitt angefügt:




    Sorry - wollte eigentlich hier posten:

    yavdr-ansible focal auf NUC10i3 etc.

    vielleicht kann ein Moderator den Post dahin verschieben... Gruß K.

    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 ()

  • Ich habe hier mal einen Log-Ausschnitt angefügt:

    Bitte zeig mal ein vollständiges Log und die Ausgabe von apt policy vdr. Grundsätzlich sollte nur ein PPA mit VDR-Paketen aktiv sein, das andere am besten mit ppa-purge entfernen, also z.B.: sudo ppa-purge ppa:yavdr/experimental-vdr

    Beim Versions-Check des vdr-plugin-satip ist nur die 2.4 installiert - müßte da dann auch die 2.5.2 erscheinen? Aber es lief ja bis gestern auch so...

    Nein, die Version des vdr-plugin-satip hat mit der Version des VDR nichts zu tun - wichtig ist nur, dass sie zum VDR passt. Die Fehlermeldung aus dem Logschnipsel würde ich so interpretieren, dass der VDR keine Möglichkeit sieht Sat-Kanäle zu Empfangen. Mir ist gerade aufgefallen, dass ich in dem PPA vergessen habe die ABI-Version hochzusetzen, dadurch haben die Plugins aus den PPAs keine Konflikte zur jeweils anderen VDR-Version. Ich korrigiere das gleich noch.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Moin,

    anbei das "apt policy vdr":

    Habe eben das Playbook nochmal laufen lassen: Jetzt habe ich 2.5.2-1yavdr0~focal... und ich habe wieder ein Bild...


    Im Anhang das syslog vor und nach dem update.


    Läuft also erst mal. Soll ich dann das ppa experimental noch entfernen?

  • Soll ich dann das ppa experimental noch entfernen?

    Ja, ein zweites PPA für VDR-Pakete macht potentiell Ärger und hilft nichts.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hi, Seeadler - danke für Deine unermüdliche Arbeit am vdr :)


    Hieß es nicht, daß das ppa für 2.5.2 auch das experimental dazu braucht?

Jetzt mitmachen!

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