Blockaden durch epg2vdr (oder scraper2vdr)

  • Hallo zusammen,


    da fragt man sich schon Tage, was mit dem DDCI nicht stimmt und den VDR per "Video datastream broken" neu starten läßt (daher mal abgeschaltet und den gdb attached), da sieht man per Zufall das hier vorbeirauschen:



    Super. :-)


    So wie es ausschaut, zieht das epg2vdr Symlink Update auf der Platte das ganze I/O System runter.
    Das muß doch sicher nicht sein, oder? Freundliches Miteinander und so... ;-)


    Reicht wohl ein usleep in der zugehörigen Schleife, oder braucht das einen größeren Umbau?


    An die zwischendurch minütige Unbedienbarkeit und totes VPS kann man sich ja zu Gunsten des EPG gewöhnen

    ;)


    42.

  • Nein, das usleep(1000) hilft nur bedingt ... dann nutzt scraper2vdr die Gelegenheit. Effekt wie vor.


    Nur epg2vdr macht dann allerdings keine Probleme.


    Es scheint, daß grundsätzliche Laden aller zusätzlichen Aufnahme-Infos aus der Datenbank ohne lokale Zwischenspeicherung stößt bei aktuellen Plattengrößen an seine Grenzen.

  • Ist deine Hardware (CPU, HDD) tatsächlich sooooo alt?

    Ich habe hier wirklich keine neue HW (siehe Signatur), aber zu broken videostream kam es hier noch nie wenn epgd & co am Werkeln sind.

    Hohe CPU-Auslastung schon (wg. Maria-DB/MySQL).

    MyVDR: yaVDR-Ansible (Ubuntu 18) - 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

  • Nö, alt nicht. Aber halt sparsam. J3160ITX mit 8 GB RAM

    CPU Last war < 50%, IO-Last um <40% mit < 2 GB RAM in Benutzung.


    Die MariaDB liegt auf einem BPi. Akzeptabel, eigentlich.

    Kann eigentlich nur die Anzahl an Aufnahmen sein, die stört. Mal schauen.

  • Hier selbst auf einem Raspi kein Problem.

    Auf die Platte werden auch nur die EPG Bilder für den Skin geschrieben - oder um welches Dateien geht es?


    Liegt es wirklich am File IO? Wie performant ist das Filesystem? Was ist es für ein Filesystem, ein lokales?


    Grüße

    Jörg

  • Fortsetzung von hier ....


    Es kann natürlich auch der externe Sql-Server sein. Aber gerade bei Remove old symlinks gibt es keinen Datenbankzugriff, nur auf Disk / Filestats.

    Was sagt den time ls -Rl /var/cache/vdr/epgimages | wc .


    Du könntest einmal probeweise /var/cache/vdr/epgimages in eine ramdisk (tmpfs) mounten und dann die Updatezeiten vergleichen (z.B. so für 1GB:sudo mount -t tmpfs -o size=1024M tmpfs /var/cache/vdr/epgimages. Die erforderliche "Size" kannst du vorher mit du -h /var/cache/vdr/epgimagesausfindig machen.


    Helmut

  • time ls -Rl /var/cache/vdr/epgimages | wc

    427405 4686676 40610575


    real 3m59,673s

    user 0m9,066s

    sys 0m14,316s


    für 230 MB.


    Als RAM-Disk (Datein zurückkopiert):
    time ls -Rl /var/cache/vdr/epgimages | wc

    427405 4686676 41425900


    real 0m11,520s

    user 0m8,385s

    sys 0m4,326s

  • Hab das bei mir auch mals ausprobiert. Die Daten liegen auf einer SSD.

    Code
    1. time ls -Rl /var/cache/vdr/epgimages | wc
    2. 252193 2632038 23179723
    3. real 0m4,321s
    4. user 0m2,319s
    5. sys 0m2,326s

    für ca 2,5 GB wohlgemerkt:

    du -h /var/cache/vdr/epgimages

    2,5G /var/cache/vdr/epgimages

    MyVDR: yaVDR-Ansible (Ubuntu 18) - 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

  • ls ist da arg langsam - ich würde da find nutzen: find /var/cache/vdr/epgimages/ -type f -name "*.jpg"


    250k Bilder dürften doch etwas viel sein - ich würde die Bilder mal abräumen (sudo find /var/cache/vdr/epgimages -name "*.jpg" -delete) und schauen, was dann tatsächlich noch von epg2vdr und scraper2vdr vom Server neu geladen bzw. an Symlinks angelegt wird.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Falls sich deine Antwort auf meinen Post bezieht: ich habe/spüre keinerlei Probleme (mehr) mit epgd & co.

    Wollte nur Fourty 2 einen zusätzlichen Vergleichswert geben.


    Prinzipiell hast du aber natürlich recht: find ist viel, viel schneller:

    Code
    1. real 0m0,921s
    2. user 0m0,406s
    3. sys 0m0,309s

    MyVDR: yaVDR-Ansible (Ubuntu 18) - 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

  • Der Diskzugriff bei Fourty2 ist wirklich sehr langsam und erklärt die langen Updatezeiten. Es sollte mind. um den Faktor 10 bis 20 schneller gehen.

    250k Bilder dürften doch etwas viel sein

    Bei Fourty2 sind es nur ca. 7500 "echte" Bilddateien, diese liegen unter /var/cache/vdr/epgimages/images.

    Aber unter/var/cache/vdr/epgimages/werden dann über 400000 Symlinks mit EventId und lfn(?) angelegt die auf diese Bilder verweisen, das sind durchschnittlich fast 60 Symlinks auf jede Bilddatei.


    Da der Inhalt von /var/cache/vdr/epgimages beim VDR-Start immer komplett mit der Datenbank abgeglichen wird, wäre eine Ramdisk vielleicht überhaupt die bessere und schnellere Lösung. Es ist nur die Frage wie groß diese sein muß. Wenn die Datenmenge wie bei davie2000 bis zu 2,5GB sein kann, müsste die Ramdisk dann schon eher für 5GB ausgelegt werden (sofern genug RAM vorhanden).

    Helmut

  • Das time ls -Rl /var/cache/vdr/epgimages | wc war natürlich kein Speedtest sondern nur dazu gedacht, um ein Gefühl dafür zu bekommen, wie schnell dis Disk oder das ganze System bei Fourty 2 ist. Ein df /var und df -i /varkönnte noch den "Fülltstand" der Disk/Partition zeigen. Es scheint aber eher so zu sein, dass dieser langsame Diskzugriff den VDR blockiert.

    Helmut

  • Nach Löschen der epgimages und vdr Neustart:
    epg2vdr: Got 7305 images from database in 549 seconds (0 updates, 7305 new) and created 28597 links

    epg2vdr: --- EPG update finished ---


    Das wäre konsistent mit dem Verzeichnis:

    - ca. 230 MB Daten (wie vor dem Löschen)

    - 7305 Bilder (etwa wie zuvor)

    - und nur noch 35900 Links. (427405 - 35900 = 391.505 nicht gelöschte Links)


    Die scraper2vdr Datenkopie liegt in /var/cache/vdr/plugins/scraper2vdr.
    Hier 4,6 GiB, die nicht zu stören scheinen.


    System-Platte ist eine 2.5" 1 TB mit ext4 fürd system und xfs für video - Unauffällig.



    Bliebe die Frage, warum die alten Links erhalten bleiben.


    Klar könnte ich die zwei Verzeichnisse ins TMPFS mounten.

    RAM wäre genug da und um die Größe muß man sich da nicht kümmern, macht das TMPFS bei Bedarf selbst.

    Z.B. /var/log, Videotext und epg liegen da sowieso schon (hatte auch mal ein Paket gefunden was das selbständig von der HDD und zurück kopierte - leider irgendwo verloren), aber ...


    ... wenn man schon lokal einen Cache anlegt, so als Plugin, sollte man sich auch ums aufräumen kümmern, oder?


    Kann natürlich, wie beim epgd (auf dem Server) per cron Job alle x Tage die Bilder, bzw. hier nur die Links abräumen. :-/


    Stefan

  • Das Verzeichnis /var/cache/vdr/epgimages nur in einer Ramdisk zu halten ist vielleicht auch nicht so gut, wenn das Einlesen aus der externen Datenbank 9 Minuten dauert.

    Es gibt die Setupoption "LoadImages", damit kann das kopieren der Bilddateien aus der DB auf die Festplatte überhaupt unterbunden werden. Ich denke, dass dann die Bilder immer direkt aus der Datenbank geholt werden.

    Im Sourcecode habe ich auch keine Referenzen auf die Symlinks gefunden. Wofür werden sie überhaupt benötigt?

    Vielleicht weiss horchi mehr darüber, und auch warum sich bei dir so viele offensichtlich unnötige Symlinks ansammeln.
    Helmut

  • Denke, die Links werden vom VDR über die Skins (hier skinnopacity) aufgerufen. Und da es z.B. Nachrichtensendungen halt x-mal gibt, ein Bild per x Links. Scheint mir logisch sinnvoll.


    Nur warum das Aufräumen - was ja offensichtlich erfolgen sollte - nicht funktioniert, wäre die Frage.


    Das per rsync von Platte in die RAM-Disk und nach Ende zurückzukopieren braucht natürlich keine 10 Minuten. Die 5 ms Delay sind auch noch da. Nicht zuviele Experimente auf einmal... ;-)


    Stefan

  • Denke, die Links werden vom VDR über die Skins (hier skinnopacity) aufgerufen.

    Da hast du recht. Dass die EPG Bilder und Symlinks unter /var/cache/vdr/epgimages liegen dürfte Standard sein (oder ein gewachsener defacto Standard).

    Und dass sich mit epg2vdr viele unnötige Symlinks ansammeln ebenso :).


    Eine Suche hier im Forum zeigt, dass es das Problem schon länger gibt. Abhilfe scheint aber nur ein regelmäßges manuelles Leeren des Cache-Verzeichnis zu sein und dieses auf einer schnellen Platte zu betreiben. davie2000 hat das löschen einmal so gelöst:

    /var/cache/epgd u.a. - wie sinnvoll bereinigen?

    Wenn die Bilder nicht mehr gibt, sollten die unnötigen Symlinks von vdr2epg automatisch entfernt werden.

    Helmut

  • Nein, das ist der epgd - der lädt die Bilder runter und schiebt sie in die Datenbank. Und da, wo sie abgelegt werden, bleiben sie erstmal liegen - das spart zwar das erneute runterladen bei Wiederholungen, aber es gibt keine Routine, die Altes entfernt.


    Das wird auch hier einmal im Monat bereinigt. "rm" .. :-)

    (Und läuft 24/7 auf einem anderen Rechner)


    Stefan

  • Indem Du in /etc/cron.d eine Datei, z.B. clean-epgd folgenden Inhalts anlegst:


    Code
    1. # /etc/cron.d/clean-epgd: crontab entries for epgd/tvsp downloader
    2. SHELL=/bin/sh
    3. PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    4. MAILTO=""
    5. # m h dom mon dow user command
    6. 30 1 1 * * root rm /srv/epgd/tvsp/*
    7. 30 1 15 * * root rm /srv/epgd/tvsp/*



    Bei mir liegen die Bilderlein in /srv/epgd/tvsp ... dies wird bei Dir anders sein, daher Pfad anpassen.


    42.

  • aber es gibt keine Routine, die Altes entfernt

    cUpdate::cleanupPictures() sollte das eigentlich machen, aber das scheint nur dann ausgeführt zu werden, wenn man mittels svdrpsend plug epg2vdr update (oder reload) einen Abgleich anstößt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)