Beiträge von klausb

    It seems, you have software decoder.

    … and what to do? The hardware supports vdpau.

    Dass neue Programmversionen immer performance-hungriger werden - oder besser: weniger auf einen schmalen CPU-/Speicher-Footprint achten (weil die Hardware ja eh immer stärker wird) ist doch leider schon (fast) normal, oder?

    Generell schon, jedoch läuft die gleiche Version bei seahawk1986 auf der gleichen Hardware ja mit weniger Last.

    Ich kenne die Situation auf Deinem Rechner nicht, ich hatte nur selber vor Kurzem das Vergnügen eines defekten Lüfters bei einem Notebook.

    Das ist nicht das Problem. Der Lüfter läuft und das auch nicht auf Volllast.

    Aber es bleibt ein Rätsel, warum das 0.7-er System bei ansonsten gleichen Bedingungen erheblich größere Last verursacht, als das 0.6-er System.

    Scheint arg hoch zu sein (kann aber an genutzten Plugins und sonstiger Software liegen) - mein ION-System sitzt das im TV-Betrieb (ohne Sachen wie epg2vdr oder epgsearch, die bei Aktualisierungen einiges an Rechenaufwand erzeugen können) auf einer Backe ab (DF1 HD ist der einzige unverschlüsselte Full HD Kanal hier im Kabel):

    ... und warum seahawk1986 bei gleicher Hardware dies Phänomen nicht sieht.


    Inzwischen habe ich mit intensive mit diversen Themen befasst, alles, was irgendwie stören könnte, deinstalliert. Die channels.conf auf ein Minimum reduziert. Die Audio und softhddevice Einstellungen vom 0.6-er System auf das 0.7-er System übertragen, etc. Schaut man sich nur den eingeschwungenen Zustand an, so bleibt es bei der schon oben dargestellten Situation.


    Hier noch ein paar Ausschnitte aus dem syslog nach Systemstart

    Erst nach diesem Neustart des VDR scheint das System richtig anzulaufen. Sieht an sich alles normal aus, denn der folgende Fehler scheint ja normal zu sein oder?


    Dies sind die Ausgaben, wenn der Ton sehr starken Jitter aufweist.

    Lässt sich in der Regel aber auch nicht immer durch Kanalumschaltung beheben. Manchmal startet auch der VDR selbst neu (nicht der Rechner).


    Typischer Output bei Kanalumschaltung wenn kein "Jitter" auftritt. Hier ZDF HD



    Gibt es vielleicht noch Hinweise auf:

    • bessere Audio Einstellungen
    • doch noch eine Idee zum Thema deutlich höhere CPU Last


    Herzlichen Dank!

    Eventuell ist der CPU Scheduler auf Ondemand eingestellt, je weiter die CPU runtergetaktet wird desto höher ist natürlich die Last aller Prozesse. +150% usw. kann da dann natürlich durchaus zustande kommen.

    Danke für den Hinweis! Offensichtlich sind in der 0.6 die cpufrequtils  installiert und unter /etc/default/cpufreq liegt ein kleines Script, das den Scheduler für alte AMD CPUs auf "performance" stellt. Das dürfte aber hier nicht zutreffen.


    Unter Ubuntu 18.04 ist das nicht installiert. Siehe dazu auch z.B. Set CPU governor to performance in 18.04

    Dort ist aber auch ein Caveat: "Your machine will probably run 10 to 15 degrees C hotter." zu sehen.


    Ich schaue also mal nach.

    Eventuell ist der CPU Scheduler auf Ondemand eingestellt, je weiter die CPU runtergetaktet wird desto höher ist natürlich die Last aller Prozesse. +150% usw. kann da dann natürlich durchaus zustande kommen.

    • Und wo schaue ich nach, bzw. wohin und wie stelle ich um?
    • Könnte es auch daran liegen, dass jetzt immer Kontextwechsel stattfinden müssen? In der Version 0.6. gab es ja keinen Prozess im User-Kontext.

    Zuerst möchte ich mich bei allen für die Hilfe bedanken. Kam leider erst heute dazu, die verschiedenen Aspekte mal durchzugehen.

    • epgsearch: Ja, danke. Das war nicht im Standardumfang.
    • Die beiden Sundteks funktionieren. Wurden per force_installund wait_for_devices aktiviert. Sonst hätte ich ja kein Bild.
    • Softhddevice: Kann ich die Einstellungen in einer .conf Datei o.ä. finden? Dann muss ich nicht via Screenshot arbeiten.


    Die Datei wird aus dem Template https://github.com/yavdr/yavdr…/templates/rc_maps.cfg.j2 generiert

    Soweit ich das sehen kann, gibt es im Paket yavdr-remote noch keine keymap und Eintrag für die ttusbir - wenn du da eine Konfiguration vorschlagen kannst, kann ich die gerne einbauen.

    Habe in rc_maps.cfg.j2 als "quick & dirty" Lösung einfach die Zeile

    Code
    ttusbir    rc-tt-1500   /etc/rc_keymaps/rc-tt-1500

    eingefügt. Die Keymap siehe rc-tt-1500.zip. Funktioniert problemlos.


    Nun zum Thema Last:


    Im 0.7 sind erheblich weniger Plugins aktiv!

    Systemlast 0.6

    Systemlast 0.7 (Ubuntu 20.04.6 LTS, Kernel 5.4.0-172)

    Fazit: Die Grundprozesse vdr (150%) und mediasrv (140%) bringen bei einem HD Sender schon erhebliche Mehrlast. Dazu kommt pulseaudio.


    NVIDIA geht damit in der Temperatur natürlich auch hoch:


    Fazit:

    • Keine Ahnung, warum die Last so stark steigt. Die höhere Last bei mediasrv kann ja nicht an softhddevice liegen.
    • Die kurzen Aussetzer (Jitter) lassen sich natürlich durch die höhere Last, höhere Temperatur und die zusätzliche Last via pulseaudio erklären.
    • Eine oder gar zwei Aufnahmen parallel zusätzlich zum Live-Stream sind nicht zuverlässig möglich
    • Das starke Lüftergeräusch ist natürlich auch nicht toll

    Nach einigem Hin und Her (siehe dazu meine letzten zwei Beiträge hier) habe ich jetzt eine stabile Standardinstallation von yaVDR 0.7 auf meinem (sehr) alten System und möchte vergleichend berichten. Ein paar Fragen sind eingestreut.

    Die beiden Varianten sind als Dual-Boot Version installiert, so dass ein einfaches Umschalten möglich ist.

    Ausgangssituation yaVDR 0.6 (stable-vdr/ubuntu trusty) unter Ubuntu 14.04.06 LTS

    Probleme im täglichen Betrieb

    • Start aus PowerOff: --> häufig schwarzes Bild (Ton läuft) / lässt sich teilweise nur durch vdr-restart (Blindbedienung bei schwarzem Bild) beheben
    • Kanal Umschalten: --> gelegentlich schwarzes Bild / beheben durch weitere Kanalwechsel
    • manchmal nutzt Umschalten nicht auf, Bild wird schwarz, vdr startet selbst neu

    Systemlast

    • Output via softhddevice
    • ein HD-Kanal TV und ein HD-Kanal
    Code
        top - 15:23:13 up 22 min,  1 user,  load average: 0,35, 0,88, 0,92
        Tasks: 153 gesamt,   1 laufend, 152 schlafend,   0 gestoppt,   0 Zombie
        %CPU(s):  1,3 be,  5,3 sy,  0,3 ni, 90,3 un,  0,1 wa,  0,0 hi,  2,6 si,  0,0 st

    Status yaVDR 0.7 unter Ubuntu 20.04 installiert mit Standard yavdr07.yml

    Installation

    • Versuch, auf Basis Ubuntu 22.04 zu installieren schlägt fehl, da dort der passende NVIDIA Treiber nicht mehr übersetzbar ist
    • Der TechnoTrend USB Empfänger (Treiber ttusbir) wird nicht automatisch erkannt. Ich finde allerdings auch keinen Eintrag, um eine Zeile in die rc_maps.cfg einzutragen --> Das entsprechende Template editiert, was aber nicht "systemkonform" ist.

    Probleme im täglichen Betrieb

    • Positiv: Beim Kaltstart hat man immer sofort ein Bild!
    • Im Menu "Timer" fehlen die Einträge
      • Suche
      • Schnellsuche
      • Timer-Konflikte
    • Suspend to Ram
      • Aufwachen funktioniert nicht / keine Fernbedienung etc.
      • einer der beiden Sundtek Sticks wird nicht gestartet (LED leuchtet nicht)
    • Kanalwechsel
      • deutlich schneller, als bei 0.6 aber
      • insbesondere beim Wechsel auf HD Kanäle "flimmern" oder "zittern" Ton und Bild einige Sekunden
      • teilweise hört dies auch nach Kanalumschalten nicht auf / Bild wird schwarz / vdr startet neu (siehe 0.6)
      • vielleicht liegt dies auch an der

    Systemlast (zum Vergleich wie 0.6)

    • Output via softhddevice
    • ein HD-Kanal TV und ein HD-Kanal
    Code
        top - 15:43:06 up 11 min,  2 users,  load average: 1,19, 1,37, 1,04
        Tasks: 188 gesamt,   1 laufend, 187 schlafend,   0 gestoppt,   0 Zombie
        %CPU(s):  3,9 be,  7,3 sy,  0,6 ni, 85,0 un,  0,5 wa,  0,0 hi,  2,6 si,  0,0 st
    • liegt deutlich höher als bei 0.6

    Nettes "Plus"

    • unter System / Gerätestatus gibt es deutlich bessere Informationen
    • In der Kanalliste werden die Sektionen angezeigt

    Fazit

    • Bin noch unentschlossen, ob ich 0.7 weiterhin nutze
    • Insbesondere die deutlich höhere Systemlast scheint zu Instabilitäten zu führen
    • wenn ich noch das ein- oder andere Plus aus der aktuelleren Version einbauen könnte, wäre für meine Hardware die Entscheidung klar bei 0.6


    Klaus

    [gelöst] Meine Neuinstallation unter Ubuntu 20.4 bricht in der TASK [yavdr-xorg : unload kms drivers] mit einem Traceback ab.

    Die Rollen nach yavdr-xorg werden dann nicht mehr ausgeführt.


    Einfach nochmal starten?


    Klaus

    Zitat

    Was sagt denn sudo apt-cache search nvidia?

    Nachtrag:

    • für Ubuntu 20.4, Kernel 5.4.0-172-generic nvidia-340 - NVIDIA binary driver - version 340.108
    • für Ubuntu 22.04.4 LTS nvidia-340 - Transitional package for xserver-xorg-video-nouveau

    Will man den original Treiber nutzen, so ist also bei 20.4, Kernel 5.4 oder evtl. 5.xx

    Man könnte auch mal https://launchpad.net/~kelebek…hive/ubuntu/nvidia-legacy probieren (ich bin noch nicht dazu gekommen, mein ION-System läuft noch mit Ubuntu 20.04).

    Werde also einen Neustart mit Ubuntu 20.4 machen.

    Bei Ubuntu gibt es doch seit Jahren funktionierende (proprietäre) nvidia-Treiber

    Ja das ist richtig, aber wie schon ganz oben bemerkt, lenken die aktuellen Treiber eben auf nouveau um.

    Code
    root@vdr7: lspci -nnk | grep -i "VGA\|'Kern'\|3D\|Display" -A2
    03:00.0 VGA compatible controller [0300]: NVIDIA Corporation C79 [ION] [10de:087d] (rev b1)
            Subsystem: Acer Incorporated [ALI] C79 [ION] [1025:0222]
            Kernel driver in use: nouveau
    
    root@vdr7:~# dpkg -l | grep nvidia
    ii  nvidia-340   340.108-0ubuntu8  amd64  Transitional package for xserver-xorg-video-nouveau

    Sonst hätte ich die ganze "Arie" überhaupt nicht angefangen.

    Nach einigen Test und Suchen habe ich jetzt den folgenden Thread gefunden: NVIDIA 340.108 driver kernel 5.11 support und werde mich mal daran entlang hangeln.


    Wichtig ist das Zitat:
    "Linux Kernel 5.4 will get full support throughout the duration of Ubuntu 20.04 LTS (source: Ubuntu kernel lifecycle and enablement stack | Ubuntu 22). Nvidia isn’t putting any effort in nvidia-340 drivers for kernels after 5.4"


    Wäre natürlich nett, wenn das im .run-file enthaltene Script gleich mal die Kernel-Version abfragt.


    Klaus

    Hmm, mein 6.6.18-Kernel (source) hat die include/linux/stdarg.h im Quellverzeichnis. Vielleicht den neuesten linux-generic-hwe-20.04-edge installieren, oder gleich die Sourcen :)

    So jetzt bin ich einen Schritt weiter gekommen ... und vor der nächsten Wand gelandet :§$%


    Habe zuerst mal die zum installierten Kernel passenden Sourcen mit apt source linux-image-unsigned-$(uname -r) geladen. Als dann die stdarg.h immer noch nicht gefunden wurde, die .RUN Datei extrahiert und die stdarg.h nach ./kernel kopiert, wo auch die anderen .c und .h Dateien liegen.

    Erfolg: Der alte Fehler tritt nicht mehr auf.

    Dafür aber eine Masse von Fehlern à la warning: comparison of integer expressions of different signedness: 'int' and 'size_t' und dann final

    Code
    /root/NVIDIA-Linux-x86_64-340.108/kernel/nv-linux.h: At top level:
       /root/NVIDIA-Linux-x86_64-340.108/kernel/nv-linux.h:122:10: fatal error: asm/kmap_types.h: No such file or directory
         122 | #include <asm/kmap_types.h>         /* page table entry lookup          */
             |          ^~~~~~~~~~~~~~~~~~

    ... und kmap_types.h finde ich nur in den Sourcen zum Kernel 3.13 meiner alten yaVDR 0.6 Installation.


    Frage: Was sagt der Experte? macht es bei den o.a. Compiler-Warnings und den Problemen mit nicht vorhandenen Dateien wirklich Sinn hier weiterzumachen oder doch besser einen Neuinstallation mit focal und Kernel 5 zu versuchen?


    Klaus

    Danke! Das werde ich mal probieren.

    Bin übrigens bei dieser Installation mit 22.04.3 LTS gestartet und aktuell auf 22.04.4 mit Kernel 6.5.0.21. Habe übrigens bei einer Testinstallation festgestellt, dass ich, wenn ich mit 20.4 starte, dann mit do-release-upgrade auf 22.04 hochziehe, nur Kernel 5.15.0 per dist-upgrade installiert wird!?

    Wie ich an die Sourcen komme, ist mir klar. Muss ich für einen aktuelleren Kernel noch andere apt Quellen eintragen?

    wird wohl *etwas* länger zur Behebung brauchen.

    Hätte ich auch erwartet, aber immerhin habe ich für eine erste Meldung nach weniger als zwei Stunden eine Antwort erhalten! Jetzt habe ich die .log Datei geschickt.


    Wo klemmt es bei dem *.RUN - Paket?

    Das Script läuft durch, bis zum Kompilieren von “NVIDIA-Linux-x86_64-340.108/kernel/nv.o”

    Dabei gibt es den Fehler:


    /tmp/selfgz1979/NVIDIA-Linux-x86_64-340.108/kernel/os-interface.h:27:10: fatal error: stdarg.h: No such file or directory

    27 | #include <stdarg.h>


    Klaus