prod ohne Patch, test mit Patch von HelmutB , auf beiden laufen Aufnahmen, auf dem prod wesentlich mehr, wie auf test.
Edit: beide mit epg Scan.
Zwei Tage sind natürlich sehr wenig, aber ich glaube, eine erste Tendenz kann man erkennen: Hat leider nichts gebracht.
Ja, genau das ist mein Problem auch: Welt sendet mit Untertitel und N24DOKU die gleiche Sendung ohne Untertitel. Wenn es keine Serie ist, wo der Untertitel relevant ist, kann du "Untertitel vergleichen" aus machen. Wenn der Untertitel relevant ist, hilft mein Patch.
Nein, der Wiederholungserkennung ist der Kanal egal. Sonst würde das ganze ja auch keinen Sinn machen.
Dein Patch ist auf meinem Testserver drin, er geht auch mit vdr 2.4.7.
Mal sehen, ob sich bei mir was ändert.
Es gibt Sender, die keine Untertitel im EPG haben und auch nicht durch epgdata unterstützt werden. Wird eine Serie, die von einem Kanal mit Untertitel schon mal aufgenommen wurde, auf so einem Kanal wiederholt, werden alle Folgen nochmals aufgenommen, weil der Untertitel leer ist. Das möchte ich damit vermeiden.
Ich habe da nie darauf geachtet, mein Server hat 32 GB Memory und wird i.A. einmal im Monat für ein Clonezilla Backup der Systemplatte runtergefahren. Da fallen mir Leaks nicht auf. Ich habe es erst festgestellt nachdem ich gezielt per Script danach gesucht habe.
dass der "epg scan off" Effekt nicht direkt das Leak behebt, sondern das tunen verhindert (welches dann eben nicht mehr das leak triggered)
Das glaube ich auch. Aber "glauben" kommt von "nicht wissen". 
Hast Du mal ein "Umschaltescript" laufen lassen?
Nein, hatte noch keine Zeit dazu, was zu basteln. Ich glaube auch nicht, dass das neue Erkenntnisse bringt. Das Verhalten wird sein, wie beim EPG Scan, nur eben extern getriggert. Ich hoffe, HelmutB ist da schon auf der richtigen Spur.
Oder das laek verhält sich auf headless Installationen anders, als eine mit Ausgabe-Plugin umd interaktiver Nutzung.
Davon gehe ich auch aus, das zappen fällt weg. Mein Server tunt ohne EPG Scan nur einen Kanal an, wenn er auch davon aufnehmen will.
Hier noch ein Update nach 6 Tagen:
produktiver Server mit EPG Scan:
2021-12-07 108470 vdr 20 0 2475052 509356 7936 S 0,0 1,6 155:02.99 vdr
2021-12-08 108470 vdr 20 0 2610224 631976 6708 S 0,0 1,9 295:11.16 vdr
2021-12-09 108470 vdr 20 0 2806832 705632 7076 S 6,2 2,2 350:57.07 vdr
2021-12-10 108470 vdr 20 0 2806832 815760 6932 S 0,0 2,5 434:37.16 vdr
2021-12-11 108470 vdr 20 0 2872368 891924 6864 S 0,0 2,7 552:20.91 vdr
2021-12-12 108470 vdr 20 0 3003408 976112 7056 S 0,0 3,0 697:45.91 vdrTest Server ohne EPG Scan
2021-12-07 157927 vdr 20 0 1427864 36156 3916 S 0,0 0,1 12:28.61 vdr
2021-12-08 157927 vdr 20 0 1427864 18620 2432 S 0,0 0,1 14:25.08 vdr
2021-12-09 157927 vdr 20 0 1427864 17336 1548 S 0,0 0,1 15:42.45 vdr
2021-12-10 157927 vdr 20 0 1428160 62256 6360 S 0,0 0,2 27:30.80 vdr
2021-12-11 157927 vdr 20 0 1428128 63784 6484 S 0,0 0,2 39:49.31 vdr
2021-12-12 157927 vdr 20 0 1428128 42536 2980 S 0,0 0,1 45:26.19 vdrAuf beiden Servern laufen Aufnahmen, auf dem Testserver natürlich deutlich weniger. Bei mir kann man wohl eindeutig eine Abhängigkeit zum EPG Scan erkennen.
Hat vielleicht die Anzahl an DVB Geräten, oder deren System einen Einfluss auf das Speicherleck?
Glaube ich nicht, beide Server haben gar keine physikalischen DVB Devices, ich nutze SATIP. Der produktive Server hat 4 virtuelle Devices, der Testserver nur 2.
Das kenne ich so eigentlich nur von Windows
Echt jetzt ? Hat mir einer Windows untergeschoben ???
Server3:~$ free -m
gesamt belegt frei gemeinsam Zwischen verfügbar
Speicher: 31777 5296 473 48 26006 25975
Auslager: 8191 4938 325Kein Wiederspruch, so kenne ich das auch.
Aber da muss es noch mehr Kriterien geben: Der Wert steht bei mir auf 60, ich habe in htop noch nie mehr wie 6 GB genutzter Speicher ohne Cache gesehen (von 32GB, also sind die 6 GB weit weg von 60%), trotzdem sind aktuell 5 GB ausgelagert. Warum auch immer ...
Das weicht vom bisherigen Verhalten ab
Ich sehe das auch so, dass für bestehende Suchtimer auf keinen Fall vom bisherigen Verhalten abgewichen darf. Macht mein Vorschlag aber auch nicht. Mit "ja" bleibt es genau so, wie es jetzt auch ist. Es kommt nur zusätzlich wieder "wenn vorhanden" dazu, mit einer kleiner Änderungen zu Verhalten, den es vor Jahren mal gab. Suchtimer mit diesem Wert kann es aber nicht mehr geben, weil ja hart auf "ja" gesetzt wird, egal, was man auswählt.
Da aber außer von mir keine anderen Posts hier mehr auftauchen, habe wohl nur ich eine Anwendung dafür und ich kann auch mit einem eigenen Patch leben. Danke für deine Anmerkungen, haken wir es ab.
SWAP-space kommt dann ins Spiel, wenn kein physische RAM mehr frei ist.
Dem Punkt würde ich gerne widersprechen, mit dem Rest hast du mich überzeugt, RES ist das was am Ende wirklich weh tut.
Der Kernel fängt durchaus schon viel früher an, lange nicht benutzte Seiten auszulagern, auch wenn es noch genug freien Speicher gibt. Meine 32GB sind sicher nie voll belegt, trotzdem habe ich 5 GB im Swap. Das wird vorsorglich gemacht (es könnte ja bald jemand Speicher brauchen) sowie um möglichst viel Speicher für Platten Cache nutzen zu können.
Ich habe das jetzt so seit meinem Post am Laufen, keine Probleme und es macht, was es soll. Bitte Feedback, ob du das übernehmen möchtest oder ob du meinem Vorschlag ablehnst.
32 GIB ?
Ja, das ist der physikalische Wert vom Host System, die VDRs (und andere Anwendungen) laufen jeweils auf einem eigenen LXC Container.
Gibt mir mal bitte Nachhilfe in Speicherverwaltung: Ich dachte relevant ist der virtuelle Speicher, der gibt an, wie viel Speicher eine Anwendung allokiert hat. Der resistente Speicher ist der Teil davon, der aktuell wirklich im physikalischen Speicher vorhanden ist. Das bestimmt das Betriebssystem über sein Swap Verhalten, die Anwendung hat keinen Einfluss darauf. Oder nicht ?
Ich widerlege mich jetzt selbst. Mein produktiver VDR Server mit EPG Scan hatte gestern gar kein Speicher verbraucht:
2021-12-07 108470 vdr 20 0 2475052 509356 7936 S 0,0 1,6 155:02.99 vdr
2021-12-08 108470 vdr 20 0 2610224 631976 6708 S 0,0 1,9 295:11.16 vdr
2021-12-09 108470 vdr 20 0 2806832 705632 7076 S 6,2 2,2 350:57.07 vdr
2021-12-10 108470 vdr 20 0 2806832 815760 6932 S 0,0 2,5 434:37.16 vdrExakt gleicher Speicherverbrauch am 4. Tag der Aufzeichnung,
Vor der ersten Aufnahme heute wurde sogar wieder ein wenig Speicher freigegeben:
108470 vdr 20 0 2798628 866720 10804 S 12,5 2,7 480:53.18 vdrNach der ersten Aufnahme heute hatte ich wieder einen zusätzliche Speicherverbrauch von ca. 64 MB gegenüber den Wert von gestern:
Zitat108470 vdr 20 0 2864172 871024 10260 S 6,2 2,7 502:35.72 vdr
Das sieht jetzt doch nicht wirklich nach EPG Problem aus. Ich denke, wir brauchen hier noch mehr Werte, von mehreren Tagen, für eine klare Aussage.
Allerdings wurde dann ja vermutlich auf dem Test-Server auch nie großartig gezappt und Worst-Case kein Sender getunt. Also wird gar keine EPG aktualisiert, richtig?
Nein, ich nutze den Testserver manchmal als Überlauf. Er hat aktuell auf 6 Kanälen EPG Daten, die durch Aufnahmen auf dem Kanal entstanden sind. Programmiert wurden die Aufnahmen über Live vom produktivem Server aus mit der remote Timer Funktion.
Edit: Ich hatte heute nochmals eine Aufnahme auf dem Testserver laufen. Das war wohl ein neuer Kanal, es gab eine minimale Änderung vom Speicherverbrauch (130 Bytes):
157927 vdr 20 0 1427996 55288 6828 S 0,0 0,2 19:26.10 vdrIch lasse den Test weiterlaufen und werde nach ein paar Tagen nochmals die Ergebnisse posten.
Allerdings ist der EPG-Scan ausgeschaltet.
Ich kann bestätigen, ohne EPG Scan kein Leak.
Mit diesem Skript und täglichem Aufruf 3 Tage lang getestet:
#!/bin/bash
MEM=`/usr/bin/top -b -n 1 | grep -w vdr | head -1`
DATE=`date +%F`
echo $DATE $MEM >> /root/vdr_memtestProduktiver VDR mit EPG Scan, jeden Tag 150 MB bis 200 MB zusätzlich:
2021-12-07 108470 vdr 20 0 2475052 509356 7936 S 0,0 1,6 155:02.99 vdr
2021-12-08 108470 vdr 20 0 2610224 631976 6708 S 0,0 1,9 295:11.16 vdr
2021-12-09 108470 vdr 20 0 2806832 705632 7076 S 6,2 2,2 350:57.07 vdrTest Server ohne EPG Scan, absolut konstanter Speicherverbrauch:
2021-12-07 157927 vdr 20 0 1427864 36156 3916 S 0,0 0,1 12:28.61 vdr
2021-12-08 157927 vdr 20 0 1427864 18620 2432 S 0,0 0,1 14:25.08 vdr
2021-12-09 157927 vdr 20 0 1427864 17336 1548 S 0,0 0,1 15:42.45 vdrVDR und Plugins Versionen für beide Server, alles aus yavdr 0.7 Repository:
vdr (2.4.7/2.4.7) - The Video Disk Recorder
conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu
epg2vdr (1.1.118-GIT) - epg2vdr plugin
epgsearch (2.4.1) - search the EPG for repeats and more
epgsearchonly (0.0.1) - Direct access to epgsearch's search menu
live (3.1.3) - Live Interactive VDR Environment
markad (3.0.18) - Mark advertisements
quickepgsearch (0.0.1) - Quick search for broadcasts
satip (2.4.1) - SAT>IP Devices
streamdev-server (0.6.1-git) - VDR Streaming ServerJa, passt. Natürlich wieder im richtiger Unterverzeichnis.