Blockaden durch epg2vdr (oder scraper2vdr)

  • Ich denke, das sollte bei epg2vdr irgendwo in den Plugineinstellungen konfigurierbar sein. Wäre schön, wenn das eingebaut werden würde.

  • es gibt verschiedene Ordner der /srv/epgd/tvsp wird vom epgd verwaltet (genauer dem tvsp Plugin) und m.E. auch aufgeräumt.


    Das TVSP Pluigin ist von Christian: https://github.com/chriszero ggf. ihn mal fragen.


    Ansonsten habe ich den Thread leider nicht komplett verfolgt und gerade keinen Überblick, ist sonst noch etwas offen und hat sich das mit den Ladezeiten geklärt?


    Grüße Jörg

  • seahawk1986

    Da das epg2vdr Plugin ja nicht notwendigerweise auf dem gleichen Rechner läuft, wie der epgd scheint mir der Ort nicht sehr zielführend. Das müßte dann in den epgd, für die Bilder aus dem epg Download.

    (=> daher cron für Server)


    Die hier ehemals 400000 Links auf die epg-Bilder für den VDR-epg werden ja eigentlich auch bei jedem EPG-Update gelöscht (schreibt er zumindest ins Log). Nur halt irgendwie nicht vollständig, sodaß sich im Laufe der Zeit Leichen sammeln (=> Garbage-Collection am VDR-Client nötig).


    Stefan

  • es kommt immer darauf an von welchem Odner wir sprechen, das mit den Links schaue ich mir gerade mit seahawk an.

    Und ja diese werden bei einem reload (ausgelöst über das Menü oder per svdrpsend) komplett gelöscht.

    Bleiben denn Links übrig für welche es keine Bilder mehr gibt?

  • Da das epg2vdr Plugin ja nicht notwendigerweise auf dem gleichen Rechner läuft, wie der epgd scheint mir der Ort nicht sehr zielführend. Das müßte dann in den epgd, für die Bilder aus dem epg Download.


    (=> daher cron für Server)

    Mir ging es erst mal um die Bilder, die auf den Clients liegen geblieben sind. Bei den EPG-Bildern für epgd müsste das jeweilige Plugin aufräumen, wenn es sie nicht direkt in die Datenbank schreibt (wie es bei epgdata.com der Fall ist).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    2 Mal editiert, zuletzt von seahawk1986 ()

  • Ansonsten habe ich den Thread leider nicht komplett verfolgt und gerade keinen Überblick, ist sonst noch etwas offen und hat sich das mit den Ladezeiten geklärt?

    Die "Lade"zeiten bedingten vermutlich die 395k Links auf 8000 Bilddateien in /var/lib/epgimages


    Soweit ich ich da kurz durchgeguckt hatte, waren alle Links gültig. Habe aber noch ein Backup, wenn man über die IDs was klären kann.

    seahawk1986 :

    Ich hatte während der Tests mal mehrmals "plug epg2vdr update" benutzt, um das Update-Delay (die 5 ms/Schleife) zu testen. Das hat also offenbar auch keine Links entfernt..


    Stefan

  • Soweit ich ich da kurz durchgeguckt hatte, waren alle Links gültig. Habe aber noch ein Backup, wenn man über die IDs was klären kann.

    Es gibt nach meiner Beobachtung keine toten Links - mit diesem Python3-Skript (benötigt das Paket python3-mysql.connector) kann man die JPEG-Dateien in /var/cache/vdr/epgimages/images/ mit den Einträgen in der imagerefs-Tabelle aus der Datenbank abgleichen lassen - es sollte die Dateien ausgeben, die nicht mehr in der imagerefs-Tabelle von epgd enthalten sind und damit keine Zuordnung zu einem Event haben:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Natürlich gibt es das Paket in Buster gerade nicht ...

    MySQL-Connector als Download


    Ich habe 439 überflüssige Bilder. Hmm...



    Auch wenn es mir - eigentlich - um die Links auf diese ging. :)


    42

  • Auch wenn es mir - eigentlich - um die Links auf diese ging.

    Dazu müsste man das Skript etwas erweitern - wenn du tatsächlich Dateien löschen willst, kannst du in Zeile 10 simulate = False setzen:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • ansonsten solltet ihr auf Client Seite so was im Log finden (sofern der logLevel nicht < 1):


    Das immer dann wenn der VDR läuft und der epgd alle x Stunden das Abholen des EPG bei den externen EPG Daten beendet hat.

    Bin mir gerade nicht sicher ob es ggf. eine Lücke gibt wenn der VDR zu diesem Zeitpunkt nicht läuft - muss ich mir im Code ansehen.

  • Also prinzipiell tat mein VDR das schon immer:


    Deshalb ist mir das mit den 400k Links ja auch nicht aufgefallen. Wenn die in ca. 3 Jahren Laufzeit gesammelt wurden hätte er trotzdem > 1000 Links pro Tag verlieren müssen. Scheint mir etwas unwahrscheinlich. Da müßte was anderes passiert sein. Nur was?


    Mein VDR läuft natürlich nicht durch, der epgd schon.


    Stefan

  • Moin,


    seahawk1986 hatte noch eine super Idee! Es sind schlicht Links zu noch bestehenden Bildern für welche es jedoch kein Event mehr gibt. Dachte damals nicht das diese ins Gewicht fallen. Es gibt aber wohl genug ewig laufenden Serien für welche die Bilder ewig erhalten bleiben. Dann sammeln sich natürlich mit jeder Ausstrahlung Links an.

    Das Cleanup ist nun so erweitert das Links gelüscht werden zu welchen es kein Event mehr gibt. Damit wurde hier einiges mehr gelöscht als die Tage davor:

    Code
    Feb 12 13:18:06 gate vdr: epg2vdr: Cleanup finished, removed (9682) images and (102249) symlinks Feb 12 07:08:37 gate vdr: epg2vdr: Cleanup finished, removed (1900) images and (3678) symlinks Feb 11 00:11:41 gate vdr: epg2vdr: Cleanup finished, removed (1542) images and (2604) symlinks

    ist erst mal im dev branch und noch im Test , könnt ihr euch wenn ihr testen möchtet gern schon holen, dazu aber erst dem epgd aktualisieren und neu starten.


    Vor dem Aufräumen mit der Erweiterung:

    Code
    root@gate~> l /var/cache/vdr/epgimages/|wc -l 
    149713
    root@gate~> l /var/cache/vdr/epgimages/images/|wc -l
    35673

    danach:

    Code
    root@gate~> l /var/cache/vdr/epgimages/|wc -l
     68511
     root@gate~> l /var/cache/vdr/epgimages/images/|wc -l
     36374


    Grüße Jörg

  • Danke. Hatte ich gestern schon gesehen:

    Code
    /var/log/vdr.log.1:Feb 16 13:56:03 roadrunner vdr: epg2vdr: Cleanup finished, removed (205) images and (576) symlinks
    /var/log/vdr.log.1:Feb 17 04:17:55 roadrunner vdr: epg2vdr: Cleanup finished, removed (7320) images and (45436) symlinks


    Stefan

Jetzt mitmachen!

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