Posts by heifisch

    Im git ist ein update.

    Damit sind die scraper Daten für geschnittene Aufnahmen über das VDR interne Service Interface wieder sofort verfügbar.

    Sollte mit live und den Skins funktionieren.

    Bitte testen.

    ~ Markus

    Hallo MarkusE .

    Seit einiger Zeit habe ich das Verhalten, dass wieder keine Scraper-Daten den frisch geschnittenen Aufnahmen zur Verfügung stehen.
    Man muss die geschnittene Aufnahme manuel scrapen, damit sie wieder verfügbar sind.

    Hast Du das Verhalten wieder geändert?

    Gruß und Danke.

    Heiko

    Mit PCIe 3.0 und 16 Lanes kannst du ca. 15,5 GB pro Sekunde auf die Graka schaffen. Bei 8 Bit pro Farbe und einer UHD Auflösung wird das dann schon eng.

    Ob es aber nun daran liegt ist schwer zu sagen.

    Ich habe hier noch mal ein wenig geforscht und hoffe, dass meine Schlussfolgerungen nicht ganz daneben liegen.

    nvtop zeigt auch RX und TX auf dem PCIe Bus an (Screenshot erste Zeile).
    Leider keine Kurve, da gibt es zwar ein Ticket, ist aber noch nicht implementiert.

    Im normalen Betrieb mit libplacebo liegt die GPU-Last bei ca. 21% und PCIe RX/TX nicht höher als 30 MiB/s.

    Wird das OpenGL OSD aufgerufen wird im Verhältnis eine sehr hohe Last erzeugt:

    Mit dem Befehl stress-ng --pci 8192 --pci-dev 0000:01:00.0 kann ich auf dem PCIe Bus noch etwas mehr Stress erzeugen.

    Das hat aber keinen Einfluss auf das Verhalten. D.h. ich erzeuge damit nicht noch mehr Freeze.
    Also ist der PCIe wahrscheinlich eher nicht der Engpass.

    Ich konnte allerdings einen Zusammenhang der Häufigkeit der Freeze mit der Größe des OSD feststellen.
    D.h. Stelle ich bei Bildausgabe von 1920x1080p die OSD-Größe auf im Plugin auf 1280x720 oder reduziere ich die OSD Größe in den VDR-Einstellungen z.B. auf 80%x80%, treten die Freeze nicht mehr bzw. nicht so häufig auf. Bin mir nicht mehr sicher, bei 80%x80% habe ich jetzt auch wieder ein Freeze gehabt...
    Wegen der schlechten Augen hatte ich das OSD auf 98%x98% eingestellt.

    Ich denke, die Ursache für die Freeze ist das OpenGL OSD.
    Das Seltsame ist, dass es nicht immer auftritt und meistens nur dann, wenn das OSD lange nicht offen war.
    Der Lautstärkebalken alleine verursacht keine Freeze.

    Ich reduziere jetzt mal die OSD-Größe, bis es nicht mehr auftritt.

    Doch das war lange mein Haupteinsatz auf einem Intel Quad Core. Aber der hat ca. 100 Watt verbraucht und das wurde mir dann langsam zu viel. Ausserdem kann softhdcuvid kein HDR und das wollte ich unbedingt haben.

    Deswegen habe ich dann softhddrm geschrieben und dann softhdodroid. Da läuft das ganze am besten und ist derzeit mein Haupt VDR.

    jojo61 Vielen Dank. Damit verstehe ich die Zusammenhänge besser und kann das Problem besser einordnen.

    Für das odroid-N2 müsste ich einen kompletten Strategiewechsel machen.
    Mein aktueller VDR hat die große HDD-Platte drin und soll mittels der Nvidia-Karte auch die Aufnahmen in HEVC transcodieren.

    Ich würde an deiner Stelle eher mit dem Problem leben. Es gibt keine Garantie das die Ursache tatsächlich der PCIe Bus ist.

    Ich habe jetzt schon so viel Energie rein gesteckt um dieses Problem zu beseitigen, dass ich nicht gerne aufgeben möchte. :wand
    Na ich gucke mal, ob ich was Gebrauchtes günstig bei Kleinanzeigen kaufen kann.
    Mit kräftiger Intel CPU und Intel-Grafik, könnte ich ja dann auch noch mal softhddrm und libplacebo testen.
    Evtl. würde dann auch das Tool pcm-pcie laufen und ich könnte mir mal die Auslastung auf dem PCIe Bus ansehen.

    Die CPU mitsamt der GPU ist sicher auch mit libplacebo am Rand ihrer Möglichkeiten.

    Was hattest Du denn für Systeme mit libplacebo im Einsatz, mit denen das bei Dir gut funktioniert hat?

    Danke aber fürs mitdenken...

    Ob die x2 tatsächlich hier die Anzahl der Lanes angibt ? Aber wenn es wirklich nur 2 Lanes sind, dann frage ich mich warum das Board der Graka keine 16 Lanes gibt. Hast du weitere PCIe Karten im Board ? Oder PCIe SSDs ?

    Es ist eine PCIe NVME mit drin.

    Was ich im Netz gefunden habe, zeigt wohl lspci -vvv mit LnkSta: Speed 8GT/s, Width x2 (downgraded) die Anzahl der tatsächlichen genutzten Lanes an.
    In der Dokumentation zum Board steht wohl auch die Einschränkung:

    Das Board ist schon sehr schwachbrüstig mit seinem 6W TDP Prozessor.
    Da könnte es schon sein, dass der Rest auch kastriert wurde.

    Deine Vermutung würde zumindest erklären, warum die Freeze mit dem neuen System nicht verschwunden sind.
    Das alte System war ein ThinkServer TS200v von 2011 mit einer Nvidia T400. Da war nur PCIe Gen1 x16 dran.

    Wenn wirklich die PCIe-Anbindung die Ursache für die Freeze ist, würde ich mich nach einem anderen System umschauen.

    Leider läuft pcm-pcie auf dem System nicht:

    Code
     pcm-pcie
     Intel(r) Performance Counter Monitor: PCIe Bandwidth Monitoring Utility 
     This utility measures PCIe bandwidth in real-time
     ...
     Detected Intel(R) N100 "Intel(r) microarchitecture codename Raptor Lake" stepping 0 microcode level 0x1c
     Jaketown, Ivytown, Haswell, Broadwell-DE, Skylake, Icelake, Snowridge and Sapphirerapids Server CPU is required for this tool! Program aborted

    Mit PCIe 3.0 und 16 Lanes kannst du ca. 15,5 GB pro Sekunde auf die Graka schaffen. Bei 8 Bit pro Farbe und einer UHD Auflösung wird das dann schon eng.

    Ob es aber nun daran liegt ist schwer zu sagen.

    Gut, ich betreibe ja das Ganze nur mit 1920x1080p50.

    Aber wenn ich es richtig verstehe, werden nur 2 Lanes verwendet:

    Code
    vdr ~ # lspci -vvvs 01:00.0 | grep -i width
                    LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <1us, L1 <4us
                    LnkSta: Speed 8GT/s, Width x2 (downgraded)

    Das wären dann ja maximal nur 2GB/s...

    Das wäre ja ärgerlich, wenn das Board zu schwach ist.
    Kann man irgendwie sicher feststellen, ob das die Ursache ist, Bevor ich mich nach einem anderen Board umschaue?

    Ja sieht nicht danach aus. War ja auch nur so eine Idee.

    Ich bin für jede Idee dankbar!

    Deswegen wird das ja per Opengl auf der GPU gemacht. Mit wievielen Lanes ist den deine Graka angebunden ?

    Das steht im Manual vom Motherboard.

    PCIe-Steckplätze:
    PCIE1 (PCIe 3.0 x16-Steckplatz) wird für Grafikkarten mit PCIe x2-Lane-Breite verwendet.
    PCIE2 (PCIe 3.0 x1-Steckplatz) wird für Grafikkarten mit PCIe x1 Lane-Breite verwende

    dmesg sagt zu PCIe:

    lspci -vvv meint:

    Hallo.

    Grundsätzlich finde ich in meiner Umgebung die Video-Ausgabe mit softhdcuvid und libplacebo alternativlos.
    Ich habe ohne libplacebo und mit softhddrm getestet, aber die Bildqualität überzeugt mich am meisten in der o.g. Konstellation.

    Leider gibt es einen kleinen Schönheitsfehler mit dem ich zwar leben würde, aber den ich doch versuchen möchte abzustellen.

    Wenn ich das OSD öffne, dann friert manchmal das Bild kurz (1-2s) ein. Das passiert nicht immer, aber häufig wenn das OSD lange nicht geöffnet wurde.
    Nachdem es weiter geht sind Bild und Ton kurz nicht synchron. Den Fehler habe ich schon sehr lange bemerkt, auch schon mit meinem alten System mit einer Nvidia T400.
    Nur mit der T400 schaffte es die Grafikkarte manchmal nicht den a/v sync wieder herzustellen.
    Wenn man das OSD kur vorher offen war, kann ich dieses Problem nicht feststellen.
    Es fühlt sich irgendwie so an, als würde das Opengl OSD schlafen und müsste geweckt werden. Wenn es dann wach ist funktioniert es einwandfrei und ohne Verzögerung.
    Das spricht doch eigentlich dafür, dass es keine Frage der Power ist.

    Das Problem tritt mit unterschiedlichen Skins auf, also getestet mit skindesigner, LCARS, klassischen Skin und skinflatplus.
    Es tritt auch mit unterschiedlichen Scalern auf.
    Mit der neuen Grafikkarte Nvidia T1000 mit 8G RAM wird der a/v sync in der Regel wieder hergestellt.
    Da merkt man also schon, dass die Grafikkarte viel leistungsfähiger ist.
    Das Sysem sollte eigentlich genug Power haben, dass es keine Frage der Resourcen ist, denke ich?
    Die Auslastung, angezeigt per nvtop, zeigt auch keine extremen Spitzen.
    Der Intel N100 läuft im performance-Mode.

    Was könnte die Ursache für diese Freeze sein?

    jojo61 Hast Du eine Idee, an welcher Stelle ich mal nachforschen kann?

    Bei mir geht es auch:

    Code
    vdr /usr/local/src # git clone --branch stable/latest git://git.tvdr.de/vdr.git
    Klone nach 'vdr'...
    remote: Enumerating objects: 32498, done.
    remote: Counting objects: 100% (32498/32498), done.
    remote: Compressing objects: 100% (7450/7450), done.
    remote: Total 32498 (delta 26191), reused 30890 (delta 24809), pack-reused 0
    Empfange Objekte: 100% (32498/32498), 7.07 MiB | 6.47 MiB/s, fertig.
    Löse Unterschiede auf: 100% (26191/26191), fertig.

    Bei mir passt der 2. Patch nicht ganz.
    Da bekomme ich einen reject:

    Diff
    --- menu.c      2025/02/20 10:23:15     5.22
    +++ menu.c      2025/02/25 15:53:43
    @@ -1608,6 +1609,7 @@
     
     bool cMenuScheduleItem::Update(const cTimers *Timers, bool Force)
     {
    +  LOCK_CHANNELS_READ;
       LOCK_SCHEDULES_READ;
       eTimerMatch OldTimerMatch = timerMatch;
       bool OldTimerActive = timerActive;

    Da fehlt das LOCK_SCHEDULES_READ, oder?

    Eine defekte NAS hat ein neues Innenleben bekommen und mit einem Raspi 5, ein recht potentes...
    Und dank PCIe konnte ich ein SATA HDD und eine SATA SSD anschließen.
    Auf dem Gerät läuft unter Gentoo der Home Assisstant und für die Video-Überwachung Frigate.
    Mit Google Coral USB TPU funktioniert die Personen-Erkennung sehr gut.
    Sonst soll die Kiste noch Backup machen und File-Service...