Posts by HelmutB

    Ich habe kurz in die Datei reingesehen. VonListGarbageCollector oder Purge habe ich nichts gefunden, nur cSchedules::Cleanup().

    Leider sagen mir diese Meldungen nichts.

    LG Helmut

    Ich habe heute den VDR ohne EIT-Filter aber mit einer 4-Tage alten epg.data gestarted.

    Zuvor habe ich in cEpgDataWriter::Perform() einen Zähler der Events Vor und Nach dem cEvents::CleanUp() eingebaut.

    Beim ersten CleanUp() werden von 176738 Events 70752 davon als veraltet gelöscht.

    Und obwohl rd. 40% der Events entfallen wirkt sich dass überhaupt nicht auf die Speichernutzung aus. Ich schätze, das es nach dem Purge in meinem Fall ca. 50 MB mehr freier Speicher seiin sollten.


    Ich habe zuerst den ListGarbageCollector in Verdacht gehabt, der "zerstört" aber wie geplant alle 70000 Events 5 min. nach dem CleanUp. Aber auch ohne GarbageCollecor wird der Speicherverbrauch nicht weniger.

    Hier die Ausgabe von Top zusammen mit den CleanUp() Meldungen aus dem syslog:

    rell : siehst du im libleak Log irgend eine Hinweis auf ein "free" durch ListGarbageCollector::Purge()?

    Ich bin mir nicht sicher, ob der Patch wirklich die vollständige Lösung deines Problems ist, da der belegte Speicher auch nach einem einfachen restart des VDR nicht mehr zur Verfügung gestanden wäre,

    Und in deiner Grafik im 1. Post geht die Speicherbelegung nach dem systemctl restart vdrwieder annähernd an die Ausgangsposition zurück.

    Ich werde das in den nächsten Tagen mit aktiven EPG auch noch vergleichen.

    Es sieht so aus, als ob mit dem "delete-d" Patch der Seicherverbrauch jetzt nach dem ersten vollständigen Transponderscan konstant bleibt. In den letzten 2 Stunden hat "top" nur einmal eine Steigerung um 8 KiB angezeigt.

    Der Eit-Filter war dabei deaktiviert.


    nvertigo : Der DVB-S2 descriptor hat nur für DVB-S Relevanz, diese Überprüfung findet aber immer statt, auch wenn es nur DVB-T oder DVB-C Descriptoren geben kann.

    Hat vielleicht die Anzahl an DVB Geräten, oder deren System einen Einfluss auf das Speicherleck?

    Das Speicherleck in nt.c hätte sich schon mit der Anzahl der Geräte vervielfacht. Mit nur einem Device erfolgt der Transponderwechsel durch den Eitscanner 120 180 mal pro Stunde. Wenn 2 Devices zur Verfügung stehen, kann der Wechsel 240 360 mal pro Stunde erfolgen - und damit auch doppelt soviel Speicher verbrauchen. Das ist auch unabhängig von der Größe der channels.conf, es wird nur mehr oder weniger oft auf den gleichen Transponder getuned.

    Bei den von mir gemessenen 700 KiB/Std. wurde nur mit einem DVB-S Tuner gescanned.


    Edit: der Eitscanner wechselt alle 20s den Transponder, das ergibt dann klarerweise 180 Transponderwechsel pro Stunde pro Device.

    kfb77 : der Speicherverbauch von EPG ich sicher ein eigenes Kapitel, Im Augenblick suche ich nur die Ursache der Vermehrung um 700KiB/Std ohne EIT.

    Ein Grund könnte vielleicht ein fehlendes delete d in nit.c bei der Suche nach einem DVB-S2 Descriptor sein.

    Ich lasse den VDR gerade mit diesem Patch laufen, das Ergebnis dauert leider noch etwas, da ich zumindest 2 Durchläufe des Transponderscans abwarten muß, um eine Ändeung eindeutig zu erkennen.

    Hier die ersten Erkenntnis ohne EIT: der Speicherverbrauch steigt ziemlich konstant um ~700 KiB/Std.

    Wenn aber zusätzlich auch der NIT-Filter deaktiviert wird, ändert sich die Speicherbelegung nur wärend des ersten Tranponderscans, in den darauffolgenden 1,5 Stunden habe ich keine Steigerung mehr beobachtet.

    Ich werde mir daher nit.c etwas genauer ansehen.

    Im Anhang die Logs mit den Ausgaben von "top".

    kfb77 : Hier mein Wissenstand, ohne Anspuch auf vollkommene Richtigkeit :).

    Virtual Memory gibt an, wieviel Speicher ein Prozess aktuell insgesamt ansprechen kann.


    "Speicher" bezieht sich aber nicht nur auf das RAM in dem der Code und Daten abgelegt sind, sondern auf alles was in den virtuellen Adressbereich "gemapt" wurde.

    Das kann auch RAM von Peripheriegeräten wie z.B. einer Grafkkarte sein oder eine Datei auf einer Disk - es wird zB für alle verwendeten Bibliotheken Virtual Memory reserviert, über die virtuelle Adresse können diese Dateien dann gelesen werden, physisch wird aber auf den Speicher der Disk zugegriffen. Ins RAM werden aus einer Bibliothek außerdem nur die benötigten Funktionen kopiert, im Virtual Memory ist der Speichebereich aber in Größe der gesamten Datei reserviert.
    Der Virtual Memory ist daher immer um einiges größer als nur der tatsächlich belegte Arbeitsspeicher.


    SWAP-space kommt dann ins Spiel, wenn kein physische RAM mehr frei ist. Dann wird der von einem Prozess gerade nicht benötigte Speicher auf eine Disk kopiert und so RAM freigemacht.


    "RES" ist daher der aussagekräftigere Wert für die Speicherbelegung.

    LG Helmut

    Der Verbrauch von physischem RAM ist schon gestiegen. Das ist die Spalte "RES" (für resident) in KiB.

    Der Steigerung wäre bei dir in den 3 Tagen 306 MiB und heute nach der Aufnahme noch einmal 66 MiB.

    Code
    1. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    2. 2021-12-07 108470 vdr 20 0 2475052 509356 7936 S 0,0 1,6 155:02.99 vdr
    3. 2021-12-08 108470 vdr 20 0 2610224 631976 6708 S 0,0 1,9 295:11.16 vdr
    4. 2021-12-09 108470 vdr 20 0 2806832 705632 7076 S 6,2 2,2 350:57.07 vdr
    5. 2021-12-10 108470 vdr 20 0 2806832 815760 6932 S 0,0 2,5 434:37.16 vdr
    6. --- nach Aufnahme
    7. 108470 vdr 20 0 2864172 871024 10260 S 6,2 2,7 502:35.72 vdr

    Man sieht es auch an %MEM vom gesamten phsischen Speicher (32 GIB ?)

    Helmut

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

    daran habe ich auch schon gedacht.

    Ich lasse gerade den VDR nur mit dem dummydevice laufen, habe aber den Eit-Sectionfilter ganz deaktiviert und die epg.dat gelöscht. Ich schalte nicht Live über alle Programme, sondern lasse im Hintergrund durch aktivierten EPG-Scan über alle Transponder durchschalten. "UpdateChannels" ist auf "neue Transponder hinzufügen" eingestellt.

    Er läuft jetzt erst seit etwas mehr als einer Stunde, für eine eindeutige Aussage ist es daher noch zu früh.


    Den EIT/EPG Filter habe ich so deaktiviert:

    LG Helmut

    Hier die Version 2 des AAC_RDS Patch.

    Darin ist der von TomJoad oben festgestellte Fehler behoben. Zusätzlich wird jetzt bei MPEG die Framegröße für jeden Frame dezidiert ermittelt, da sich z.B.. bei "JAM FM" über das Padding-Bit die Größe jedes Frames um +/- 1 Byte zum Vorgänger ändert.


    Das Frame- und Bufferhandling von AAC unD MPEG ist jetzt vereinheitlicht, und durch das Argument "-x" kann das Anzeigen eines Hintergrundbilds komplett abgeschaltet werden - das benötige ich derzeit für xineliboutput das mit Standbild keinen Ton ausgibt.


    Edit:

    Eine klein Ergänzung: Das AAC-RDS Parsing ist unverändert. Ich habe gestern noch eine kurze Aufnahme vom "Bremen Eins" durch ts2shout mit gepatchtem ffmep laufen lassen. Da auch hier keine RDS Daten angezeigt wurden, gehe ich davon aus, dass derzeit auf diesen Sendern (noch) kein RDS übertragen wird.

    Die die alten ARD Radioprogramme mit RDS im MPEG1 Audiostream bald abgeschalten werden, habe ich nach einer Lösung gesucht, diese Informationen auf einfache Weise aus dem neuem Audio-Sendeformat AAC-LATM herauszuholen. Einen vollständigen AAC-Bitstream Parser wollte ich mir dazu nicht antun, ich gehe die Sache umgekehrt an und suche dazu in den letzten 128 Byte jedes AAC-Frames nach einem Data_Stream_Element <DSE> mit RDS Daten.

    Da es sich bei AAC sich um einen Bitstream handelt, werden die Daten zuerst an eine Bytegrenze geschoben und dann versucht beim Rückwärtslesen den Beginn des <DSE> zu erkennen.

    Soweit ich es beurteilen kann, werden damit bei allen neuen ARD Radioprogrammen die RDS Daten gefunden und angezeigt - nur bei "Bremen 1..4" sehe ich im Gegensatz zu den "alt_*" Prgrammen nocht nichts.

    Die Programme "hr1" bis "hr4" haben dei RDS Daten nun auch direkt im Audiostream, das war glaube ich im September noch nicht der Fall.


    Im Anhang der radio-1.1.0-00-AAC_RDS.patch für das radio-plugin-1.1.0.

    Für die Sender mit eigener RDS-Pid gibt es noch den passenden Erweiterungspatch radio-1.1.0-01-AAC_RDS-RdsPid.patch, damit muß aber auch der VDR gepatcht werden. Der VDR RDSPid Patch ist noch unverändert zu hier, der Link https://www.vdr-portal.de/inde…2-vdr-2-5-6-rdspid-patch/.

    Helmut

    it is a little difficult to understand this firmware loading.

    To decide whether the external firmware has to be loaded, register 0x20 is checked for a value > 0. The description of bit 1 if it is set: "Microcontroller has been reset by an abnormal event".

    Maybe this means also, that a factory default firmware is loaded through this reset (and thus, a previously loaded external firmware is replaced). If so, the ondemand firmware loading would have a reason.


    To find out whether it is really possible to do it without additional firmware uploads would requires more tests, but there is no guarantee that it will work at all.

    Since you can live with the short delay when changing frontends, this is probably the best way for now.

    BR Helmut

    Hi,

    if it worked with this kernel drivers before, then there is no need to change it.

    It rather seems, that my patch prohibits the firmware loading completely.

    Try wirbels suggestion from post #21 and comment out the single line. The Firmware should then be loaded once on first frontend access.

    Helmut

    On which driver base you are building the modules?

    The messages in your very first post

    Code
    1. cx88xx: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68,autodetected], frontend(s): 2

    and from today look a little different

    Code
    1. cx8802: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68]

    Helmut

    Here is a patch for the cx24116 kernel driver that should avoid the unnecessary firmware loads after closing and reopening the frontend (but hopefully not the very first).


    BR Helmut

    Hi,

    I found a datasheet for the cx24116 with register description. There could be an easy way, to avoid unneeded firmware reloads, but this needs a driver patch. I will post it on the evening.

    Helmut

    Hi,

    can you post the lines from your channels.conf for the programs you want to receive and the output of vdr in syslog (or of 'Journalctl -u vdr').


    Try to access these card with a different software, e.g. use w_scan2 (and select the adapter with the '-a' option) to scan the transponders for a LOCK.


    Helmut