Etwas frist Speicher VDR, Streamdev, SoftHdDevice, ffmpeg, VDPAU? VDR

  • Und dann bitte nurnoch EPG-Scan für die Favoriten und nicht mehr für jeden Sender in der Kanalliste.



    das würde die Situation auf minimalistischen Systemen (ARM) sicher entspannen.


    @ SHF


    Wir hatten zum Test anfangs auf den Systemen auch explizit EPG Scan vollständig deaktiviert. Trotzdem erhöht sich der Speicher stetig auf 64 bit Systemen. Es geht wohl mehr darum, einen prinzipiellen Fehler zu finden

  • Wir hatten zum Test anfangs auf den Systemen auch explizit EPG Scan vollständig deaktiviert. Trotzdem erhöht sich der Speicher stetig auf 64 bit Systemen. Es geht wohl mehr darum, einen prinzipiellen Fehler zu finden

    Ich hatte die Diskussion schon verfolgt und einen simplen Fehler bei den EPG-Daten schliesse ich auch aus. Allein schon, weil die epg.data nicht unendlich anwächst (wenn das der Fall wäre, würde auch ein Neustart nichts bringen).


    Wobei ich dem, was die Sender so als EPG liefern, nach dieser Geschichte, trotzdem nicht über den Weg traue.


    Ich hatte beim Blick in die epg.c nur Idee mal die bekannten, großen Brocken mit zu zählen, wo das einfach zu machen ist. Dann sieht man auch genauer, was mit dem Rest passiert und kann den VDR trotzdem weiter nutzen wie gehabt.
    Und das EPG ist ja nun definitiv der grösste Brocken. Prinzipiell muss man ja bloss die Objekte mit zählen (+ den RAM für Titel, Beschreibung usw. natürlich).
    Aber wenn ihr meint, dass das keinen Sinn macht ... war halt nur so eine Idee.


    Für den Favoriten-EPG-Wunsch kann man auch (erst mal) das Plugin noepg benutzen.

    Das Plugin ist mir bekannt, das habe hatte ich auch in Verwendung. Auf dem neuen Rechner hab ich es wohl nicht mehr drauf, da ich es eigentlich nicht benötige.


    Ich will das Thema hier nicht unnötig auswalzen, also nur ganz kurz, worauf ich eigentlich hinaus wollte:
    Der EPG wird periodisch auf der HDD gespeichert (zumindestens wird die Datei dauernd geändert).
    Muss er dann auch zusätzlich für alle Kanäle im RAM liegen? Würden da nicht die zuletzt besuchten 50 oder so reichen?
    Die meisten EPG-Daten werden bei mir eh nur von epgsearch durchsucht, oder wenn ich nach eine Wiederholung suchen lasse. Und da kann ich durchaus mit einer Sekunde fürs nachladen leben.

    Gruss
    SHF


  • Ich hatte ja in VDR 2.3.5 ein Speicherleck in cSectionSyncerHash gefixt. Nun habe ich auf meinem vor einiger Zeit neu aufgesetzten VDR mit softhddevice als Ausgabe gesehen, daß dort immer noch der Speicherbedarf stetig ansteigt (um etwa 1GB pro Tag!). Nachdem ich den VDR mal ohne softhddevice gestartet habe blieb der Speicherbedarf auch über längere Zeit konstant. Es liegt also nahe, daß softhddevice noch ein Speicherleck hat.


    Bevor ich Zeit und Mühe investiere wollte ich aber erstmal fragen:


    - Wurde der Sourcecode von softhddevice inzwischen konsolidiert, und gibt es jetzt eine Quelle, auf der man aufbauen kann?


    - Wenn ja, wo?


    - Wenn nein, welches ist die noch am besten gepflegte Quelle?


    - Hat inzwischen schon jemand etwas zur Behebung des Speicherlecks getan?


    Klaus

  • Hi,


    in der MLD setzen wir dieses Sourcen ein: https://github.com/jojo61/vdr-plugin-softhddevice

    Ob es andere aktiver entwickelte Sourcen gibt, weiß ich aber nicht.


    Und alternativ bieten wir das softhddevice mit opengl OSD auch noch aus diesen Sourcen an: https://github.com/louisbraun/softhddevice-openglosd


    Claus

    MLD 5.1 mit vdr 2.2 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM -
    WD Green 12TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.4 mit vdr 2.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.1 mit vdr 2.2 - Banana Pi - softhddevice
    MLD 5.0 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT
    MLD 2.0 mit vdr 1.6 - SMT-7020s - 80GB HDD

  • - Wurde der Sourcecode von softhddevice inzwischen konsolidiert, und gibt es jetzt eine Quelle, auf der man aufbauen kann?

    Der vpp_support Zweig aus https://github.com/pesintta/vdr-plugin-softhddevice dürfte die aktuellste Variante sein (HEVC + VPP Support, VDPAU funktioniert auch). Bis auf den Merge für die Hardwarebeschleunigung des OSD mit VDPAU, das in softhddevice-openglosd steckt, sollte da alles drin sein, was da in der Zwischenzeit aufgelaufen ist.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • The vpp_support branch of https://github.com/pesintta/vdr-plugin-softhddevice probably the most current version be (HEVC + VPP support VDPAU also works). Except for the Merge for hardware acceleration of the OSD with VDPAU that is in softhddevice-open glosd, everything should be in there, what is there accrued in the meantime.

    I agree with this. I forked vpp_support and added Louis's VDPAU openglosd support to it. I started adding in gles2 (from rella) as well but I have no device to test so I stopped.

  • Auch wenn ich mich wiederhole. Bei der letzten Suche, war das Speicherleak, auch nicht weg, wenn mal alle SoftHdDevice Funktion auf noop gesetzt hatte.


    Code
    1. 19:09:22 up 21 days, 11:38, 1 user, load average: 0.30, 0.19, 0.16
    2. 0000000000400000 1456K r-x-- vdr
    3. 000000000076b000 68K r---- vdr
    4. 000000000077c000 8K rw--- vdr
    5. 000000000077e000 388K rw--- [ anon ]
    6. 0000000001bd8000 136K rw--- [ anon ]
    7. 0000000001bfa000 240616K rw--- [ anon ]

    Ist aber uralt VDR mit uralt SoftHdDevice.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • @Klaus,


    was mir aufgefallen ist, das im codec.c vom softhddevice, die Funktionen


    avcodec_decode_audio4()

    avcodec_decode_video2()


    von ffmpeg genutzt werden, die eigentlich schon als deprecated gelisted sind. (seid der 3.1 Version von ffmpeg)


    Gruß,

    Roland

    1x OctopusNet mit 2x DVB-S2 u. 2x DVB-C
    1x Zotac ITX-A Atom 330 als Client MLD 5.4.0-64bit
    1x Raspberry 3 als Client MLD 5.4

    1x Raspberry 2 als Client MLD 5.4

    1x Raspberry 1 (staubt gerade so vor sich hin) ;)
    1x Cubietruck

    1x MCC 100
    1x BananaPi

    1x Zotac CI327 (https://www.zotac.com/de/product/mini_pcs/ci327-nano)

    The post was edited 2 times, last by rfehr ().

  • Hi,


    die Funktion avcodec_decode_video2 in codec.c laesst sich ersetzen mit


    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

  • oder durch als *ersatz function


    Code
    1. used = decode(video_ctx, frame, &got_frame, pkt);


  • Ich habe jetzt einfach mal etwas experimentiert und durch schrittweises Weglassen von Funktionsaufrufen versucht, mich immer weiter in den Code von softhddevice hineinzuhangeln und zu schauen, wann der Speicherbedarf noch ansteigt und wann nicht mehr.


    Normalerweise holt sich softhddevice bei mir etwas über 1GB pro Tag und gibt es nicht mehr frei. Nach einigen Tagen ist dann der Speicher voll. Wenn ich in video.c in der Funktion VaapiQueueSurface() die Zeilen zwischen


    /* Queue new surface and run postprocessing filters */


    und


    pthread_mutex_unlock(&VideoMutex);


    ausser Betrieb nehme, also so:

    dann wird kein Bild mehr wiedergegeben (nur noch Ton), und der Speicherbedarf bleibt auch über lange Zeit konstant.


    Das bedeutet wohl, daß irgend etwas, was in diesen Zeilen geschieht - oder etwas, was an anderer Stelle passiert oder fehlt, aber durch diese Zeilen ausgelöst wird - das Memory-Leak verursacht. Der Fehler liegt damit eindeutig in softhddevice (oder von diesem benutzen Funktionen).


    Weiter bin ich leider nicht gekommen, dazu fehlt mir einfach der Überblick über das ganze Thema Software-Decodierung. Aber vielleicht kann mit dieser Information ja jemand etwas anfangen, der sich in der Ecke besser auskennt...


    Klaus

  • Blöde Frage, weil es einem sofort ins Auge springt:

    Im Thread-Titel steht "VDPAU", der Fix ist für VAAPI.

    Das bedeutet doch, dass es noch ein weiteres Problem geben muss?

    Gruss
    SHF