Posts by nvertigo

    kfb77 :


    Ab wann swap benutzt wird, legt der Parameter /proc/sys/vm/swapiness fest. Vereinfacht gesagt: liegt dieser Wert bei 60 wird der kernel bei 60% ram-Nutzung anfangen, swap zu benutzen (natürlich nicht für alle Prozesse gleich - aktuelle Nutzung, Priorität, Niceness und/oder Echtzeit-Flag spielen eine Rolle welche Prozesse in welchen Teilen ausgeswapt werden. Meine Prozent-Umrechnung hinkt natürlich, aber erklärt schön, wie swapiness funktioniert.

    Hallo Zusammen,


    ich benutze den vdr seit über 10 Jahren (btw: danke Klaus!). Ich erlebe seit dem einen zunehmenden Speicherverbrauch von ca. 30 MB / Woche (ich vermute das ist das Leak auf das Klaus sich in dem Thread mit der rrd-tool Grafik und dem perl script bezieht).


    In der Zeit zwischen Anfang und Mitte Mai bemrkte ich plötzlich einen Memory leak von 120 MB bis 200 MB pro Tag. Da der vdr trotzdem stabil funktioniert, kann ich nicht genau sagen, wann es begonnen hat. Zu dieser Zeit benutzte ich vdr 2.4.1.


    In diesem Zeitfenster habe ich updates für gcc (10.x -> 11.x), glibc (2.32 -> 2.33) und die Umstellumg auf libglvnd gemacht. Mittlerweile habe ich vieles versucht:


    • ganzes system mit gcc-10.3.0 neugebaut
    • zu vdr-2.2.x downgraded
    • zu vdr-2.4.7 geupdated (nutze ich auch im Moment)
    • zu vdr-2.5.6 geupdated
    • xineliboutput anstelle von softhddevice benutz
    • diverse ffmpeg Versionen >=4.2

    Nichts hat das leak beeinflußt.


    Ich hatte dann die Kombi softhddevice (bzw. xineliboutput), libglvnd, nvidia opengl und vdpau und ffmpeg in Verdacht. Da meine Distro (gentoo) x11 ohne linglvnd nicht mehr unterstützt, konnte ich das nicht weiter testen - aber nach den Berichten von kfb77 können wir Ausgabeplugin + nvidia-Schrunz wohl als Ursache ausschließen.


    Leider konnte ich ein Dpwngrade auf glibc-2.32 nicht testen, da gentoo das Downgrading von glibc nicht unterstützt.


    Ich habe seit gestern das abschalten des epg scans getestet, aber das leak besteht fort. Könnte es also sein, dass nicht der epg scan an sich, sondern das Tuning das leak triggert (da epg scan tuning triggert, wäre es ein indirekter epg scan Effekt)?


    Wie eingangs erwähnt, variiert das Leak in meinem Setup. Ich glaube (keine scriptbasierten, standarisierten, reproduzierbare Messungen, aber 7 Monate empirisches zappen... ;) ), die Anzahl der Kanalwechsel (tuning), als auch der angezappte Kanal (zdf hd mehr als die anderen 720p Kanäle mehr als sd Kanäle) einen Einfluss auf des Ausmaß des Leaks. Ausgelöst durch glibc-2.33 (und neuer - mittlerweile nutze ich 2.34) auf einem 64bit System. Wie schon gesagt, dass ist nur eine Vermutung.


    kfb77 :


    Kannst Du auf Deinem Testserver mal ein Script laufen lassen, dass die Kanäle wechselt? Mit epg scan abgeschaltet und ohme Kanalwechsel, habe ich auch kein Leak mehr - aber das dürfte wohl kein üblicher Usecase sein... ;)

    louis :


    Habe gerade epg2vdr und scraper2vdr gupfated, und dabei wieder epgdata und das scraper2vdr Verzeichnis gelöscht. Nach dem ersten vdr Neustart hatte ich wiede genau die von mir beschriebenen Phänomene. Habe dann den vdr gestoppt und gestartet; und - tatata - alles war wieder gut. Verstehe mich nicht falsch: jetzt, wo ich das weiss, ist das ok. Aber vieleicht interessiert es Dich ja. Hier mal drei Logschnipsel (1. Vdrstart nach sleep; 2. Erster Vdrstart nach Löschen von epgdata und scraper-dir; 3. "Mach alles wieder gut"-Vdrrestart):


    Sieht also so aus, als ob scraper2vdr bei einem Start nach dem Löschen von epgdata und scraperdir nur unvollständig die Aufnahmen scrapt. Habe heute leider keine Zeit folgendes zu testen: epgdata und scraperdir löschen, und warten, ob und wann er den scraper-Lauf macht, den der Restart erzwingt. Vieleicht könnte das ja mal jemand, der hier mit liest.


    Louis: Danke für Deine großartigen bunten Plugins, Deinen Support und Deine Geduld!


    Gruß, Ingo


    EDIT: Mist - falsches Forum. Könnte ein Moderator das bitte in den epgd-Thread vrschieben? Sorry & Danke.

    louis :


    Hatte es heute morgen wohl etwas zu eilig, da ich los musste. Ich hatte zwar den scraoper-Lauf im log gesehen, abr wohl nicht genau genug hingeschaut - war wohl doch noch nicht alles geholt. Jetzt sind in series und movies , sowohl im epg, als auch in ecordings alle Bilder da, wo sie sein sollen - sorry, das nächste mal warte ich längr nach dem Löschen des scraper-dirs, bevor ich die Pferde verrückt mache.

    Ja. In der kleinen EPG-Ansicht wirds ja auch angezeigt.

    Code
    1. ls -la /var/vdr/scraper2vdr-images/movies/97365
    2. total 492
    3. drwxr-xr-x 2 root root 4096 May 15 10:27 .
    4. drwxr-xr-x 1284 root root 36864 May 15 10:27 ..
    5. -rw-r--r-- 1 root root 217386 May 15 10:27 fanart.jpg
    6. -rw-r--r-- 1 root root 213898 May 15 10:27 poster.jpg
    7. -rw-r--r-- 1 root root 20294 May 15 10:27 poster_thumb.jpg


    Was mir dabei auffällt: Bei Serien wird poster angezeigt und daneben scrollte der Text. Bei Filmen wird poster angezeigt OHNE Text daneben.


    Hatte mir heute morgen das neuste aus dem git geholt und das scraper-die gelöscht.


    Muss jetzt arbeiten - kann erst später weiter testen.

    louis :


    Leider läuft das mit den Aufnamen immer noch nicht rund - für Serien


    Wenn ich die Bildergalerie Aufrufe im Log:


    Also keine Bilder aus dem Aufnahme Verzeichnis.


    Bei Movies ist es noch blöder. Da kommt in der Bildergalerie gar nichts mehr - auch kein einziger Bildzugriff von skinnopacity. Weder auf das scraper2vdr Verzeichnis noch auf das Aufnahmeverzeichnis. Sorry.

    Asta :


    Ja. So sieht es bei mir auch aus. Guck mal ein paar Seiten weiter vorn. Da habe ich auch noch die Liste der Bilder in der DB. Da gibt es poster, fanart und banner. Ich gehe davon aus, das Louis das längst verstanden hat, und fragen wird, wenn er weitere Infos benötigt. Lassen wir ihm doch einfach etwas Zeit.


    BTW: Ich finde den Service von Euch Dreien großartig!!!

    Nein, leider nicht. Die Bilder werden unter /var/cache/vdr/epgimages/ abgelegt. Filme zeigt skinnopacity auch korrekt an. Nur Serien kommen zur zeit keine. Ich denke das epgd korrekt scrapt, irgendwie scheint es danach zu haken. Wie kann ich nopacity dazu bringen mir mehr log Meldungen zu bringen um zu schauen ob der skin versucht bei Serien Cover zu laden. Dann könnte ich schauen ob das Cover korrekt gescrapt wird.


    Gesendet von meinem GT-I9100 mit Tapatalk 2


    Bei mir ist es so: epgd scrapt richtig und vollständig. scraper2vdr holt aber fanart*, banner* und poster* nicht ins vdr FS. Skinnopacity versucht diese aber zu laden,mhat also die Info, dass die Dateiennda sind...


    Guck bei skinnopacity kal im Plugin-Setup dennersten Eintrag bei Allgemein an.


    Gruß, Ingo

    Plugin baut gerade mit diese Änderung:


    Aber weshalb ich ImageMagick in verdacht habe: das Bild ist ok - beim nächsten mal funktioniert genau das gleiche Umschalten mit Bildanzeige ja...


    Gruß, Ingo

    Moin asta,


    Ich hatte vor zwei Tagen ein ähnliches Problem.
    yaVDR nimmt für die Bilder /var/cache/vdr/epgimages/series bzw movies
    Bei mir lagen die vom selbst kompilieren aber noch unter /var/cache/vdr/plugins/scraper2vdr/...
    Nach verschieben meiner alten Bilder in das neue Verzeichnis wurde wieder alles angezeigt.
    Eventuell ist es bei dir ja das gleiche...


    Um das Kopieren zu vermeiden - ist ja irgendwie lästig:

    Code
    1. scraper2vdr (0.1.2) - 'scraper2vdr' plugin
    2. -i <IMAGEDIR>, --imagedir=<IMAGEDIR> Set directory where images are stored
    3. -m <MODE>, --mode=<MODE> mode can be client or headless, see README

    Ich habe den GIT Stand, dort wurde mehr auskommentiert als die beiden Zeilen...


    NACHTRAG
    Ich habe die Sachen wieder einkommentiert, bis auf die beiden Zeilen, nun tut sich wieder was:

    Code
    1. root@uti-srv02:~# tail -f /var/log/syslog | grep epgd
    2. May 12 23:48:29 uti-srv02 epgd: 843 DVB pending, mergeepg done after 32.267 seconds
    3. May 12 23:50:22 uti-srv02 epgd: 852 DVB pending, mergeepg done after 38.965 seconds


    Bei mir funktioniert

    Code
    1. ca52975 - (vor 11 Stunden) fixed handler buf (workaround) horchi (origin/master, master)


    Scheint wirklich ImageMagick zu sein:


    Full Backtrace anbei.


    Welche ImageMagick-Version empfiehlst Du? Oder lohnt es sich komplett auf GraphicsMagick umzustellen - ich kann nicht beide parallel installieren.




    Hilft das? In der DB ist jedenfalls mehr als im FS.