Posts by cinfo

    Quote
    avatar-default.svg rkp schrieb: Muss ich denn den X-Server vor dem Start von softhddrm stoppen?

    Ja, es darf keinen anderen DRM-Client geben, der gerade als Master fungiert (ich weiß auch nicht wie gut das "Loslassen" der Clients mittlerweile funktioniert, angeblich darf ab Kernel 5.8 ein DRM-Client seinen Master-Status ohne Root-Rechte abgeben) - also am besten yavdr-xorg.service, xlogin@vdr.service und x@vt7.service maskieren und den Rechner neu starten, dann sollte softhddrm beim Start der DRM-Master werden können.

    aktuelle Problemlösung für NUC10/11 Geräte gefunden. Der 5.17.x Kernel fragt jetzt wieder sauber den

    Set CPU governor Status ab

    Dieser kann einfach beim Start vom BM2LTS Image v4.1.42 in der /etc/rc.local gesetzt werden.

    einfach folgende Zeile in die rc.local einfügen.

    echo powersave | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor


    rc.local Bsp.


    mit

    apt install cpufrequtils

    und dann auf der Konsole cpufreq-info kann man sich die Taktfrequenz der Intel CPU anzeigen lassen.

    Code
    1. root@BM2LTS64nDD:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009Bitte melden Sie Fehler an cpufreq@vger.kernel.org.analysiere CPU 0: Treiber: intel_pstate Folgende CPUs laufen mit der gleichen Hardware-Taktfrequenz: 0 Die Taktfrequenz folgender CPUs werden per Software koordiniert: 0 Maximale Dauer eines Taktfrequenzwechsels: 4294.55 ms. Hardwarebedingte Grenzen der Taktfrequenz: 400 MHz - 4.20 GHz mögliche Regler: performance, powersave momentane Taktik: die Frequenz soll innerhalb 400 MHz und 1.60 GHz. liegen. Der Regler "powersave" kann frei entscheiden, welche Taktfrequenz innerhalb dieser Grenze verwendet wird. momentane Taktfrequenz ist 900 MHz.


    Damit sollten keine Probleme mehr mit

    Quote


    die CPU läuft bei 60-100%

    auftreten

    Quote

    Leider bleibt das Problem mit der Berechtigung und ich habe keine Ahnung, wie ich das Plugin mit root-Rechten starten kann. :/


    Viele Grüße

    Stubi

    da wäre mal @seahawk1986 gefragt -- da ich leider ein anderes Ubuntu 22.04 VDR-Image nutze


    Quote

    P.S. Sorry, dass ich immer so lange für die Antworten brauche, zur Zeit kann ich nur sehr selten und nur kurz "basteln", weil wir ein 8 Wochen altes Kind im Haus haben... :love:

    kein Problem das habe wir alle durch :saint:8)8|

    kann das so nicht bestätigen -- hier ist soweit, mit den oben geschilderten Problem, alles Ok --> nutze NUC8/10/11 und DD-Net oder NetCeiver mit VDR-2.6.1

    Auch der VDR-Headless Server in VM-Ware läuft mit Ubuntu 22.04 und Kernel 5.17.4 sauber.


    Was auffällt ist das Die Temperatur der Hardware etwas höher ist als bei Ubuntu 20.04 -- aber alles noch im normalen Rahmen.

    Das Ausgabe-Plugin ist hier softhddrm für VAAPI.


    Kodi 19.4.2 ist soweit alles OK was VNSI betrifft - Addons wie youtube (nicht getestet)

    -- ffmpeg zur Ubuntu-Version selber erstellt

    für VAAPI wir genutzt

    DRM - NUC10

    Code
    1. # sensors
    2. coretemp-isa-0000
    3. Adapter: ISA adapter
    4. Package id 0: +63.0°C (high = +100.0°C, crit = +100.0°C)
    5. Core 0: +60.0°C (high = +100.0°C, crit = +100.0°C)
    6. Core 1: +60.0°C (high = +100.0°C, crit = +100.0°C)
    7. Core 2: +60.0°C (high = +100.0°C, crit = +100.0°C)
    8. Core 3: +61.0°C (high = +100.0°C, crit = +100.0°C)
    Quote

    Meine nächste Frage ist, ob es sich wirklich lohnt, den VDR selbst in UHD-Auflösung laufen zu lassen, wenn die Auflösung der Sender max. 1080p ist. Ist dann das OSD nicht eventuell nur unnötig träge?

    das macht der VDR nicht -- ist aber für den NUC kein Problem


    So läuft es jetzt erst einmal sauber mit sofhdvaapi:

    Aber mit dem Adapter USB-C auf HDMI ?


    Aber das softhddrm nicht sauber geladen wird ist komisch -- konnte aber an der softhddrm.conf Datei liegen


    Poste doch mal bitte die Ausgabe von vdr --showargs


    Quote
    drm:FindDevice - failed to authorize drm magic: Keine Berechtigung

    softhddrm muss als root laufen weil der Kernel das bei drm so haben will


    Wichtig wäre noch die Pluginversion "sofhddrm OHNE lipplacebo" zu nutzen



    Bsp. softhddrm.conf für Full HD

    Quote

    Ich melde mich wenn, ich wieder Zeit z. Testen habe ...

    ok-->

    - was macht die Kodi / tvguide - Lösung ---> wie sieht hier das Ergebnis aus?


    - poste doch mal bitte Deine sensors Ausgabe

    Quote

    Danke, zuerst zum Hauptprob. CPU 100%:


    Soweit ich das sehe steigt die CPU Last sobald man einen SD-576i Sender wählt. Je mehr Bewegung im Bild desto mehr Überlastung.

    Startet man das Menü oder wählt einen 720p Sender sinkt die Last wieder.

    Hm, kann ich hier nicht nachvollziehen

    poste doch mal bitte Deine sensors Ausgabe

    --> was macht die Kodi/tvguide - Lösung ---> wie sieht hier das Ergebnis aus?

    Quote

    Jetzt probiere ich erstmal (wenn ich etwas Zeit finde), das USB-C-HDMI-Konstrukt an den Receiver zu hängen und dem VDR dabei das DD-Signal im Passthrough zu entlocken.

    Wenn das sauber läuft, könntest Du bitte noch einmal DRM_Ausgabe.sh über das System laufen lassen und die Ausgabe hier posten?

    Für das beste Bild am NUC11PAH wäre es das softhddrm Ausgabe-Plugin incl. "HGL HDR" bei UHD TV

    Quote

    Beim ersten Start (zumindest nach Factory) fährt es ja im KODI Mode hoch. Die Auflösung dürfte da default größer FullHD sein, da mein FHD Sony TV meint "Signal nicht unterstützt".

    (Auch nach route66 mit Mode Kodi-Mcli)

    tausche mit die Dateien aus dem Anhang -- damit sollte Kodi in Full HD starten


    Quote

    die CPU läuft bei 60-100%

    stoppe noch einmal den Plexserver über route66

    Ich glaube das der NUC11PAH durch das Ausgabe-Plugin vom VDR blockiert ist um den Speaker-Test zu machen

    Also wäre es für den Test gut dieses Ausgabe-Plugin (hier müssen dann später die Änderungen in den Code vom Plugin) einmal abzuschalten mit

    Code
    1. vdrctl disable softhddrm
    2. oder
    3. vdrctl disable softhdvaapi
    4. reboot

    nach dem Neustart bleibt das Bild am TV schwarz am VDR.

    Jetzt den VDR stoppen mit killall -g vdr , dann die Speaker-Test erneut machen


    speaker-test -c2 -D hdmi:1

    oder

    speaker-test -t wav -c2 -D hdmi:1

    ...

    Code
    1. [ 1.986486] i915 0000:00:02.0: [drm] GuC firmware i915/tgl_guc_62.0.0.bin version 62.0 submission:disabled
    2. [ 1.986511] i915 0000:00:02.0: [drm] GuC SLPC: disabled
    3. [ 1.986518] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9 authenticated:yes
    4. [ 1.987532] i915 0000:00:02.0: [drm] Protected Xe Path (PXP) protected content support initialized

    wird denn jetzt diese Firmware geladen? unter /lib/firmware/i915/

    Code
    1. tgl_guc_62.0.0.bin
    2. tgl_huc_7.9.3.bin


    wenn nicht dann von hier holen


    sollte der NUC am TV hängen wäre da der ARC zum Receiver zu prüfen

    ja das ist dann wenn der VDR doch noch läuft -- mal mit top auf der Konsole auch kontrolliert ob der VDR auch beendet ist.

    Oder wenn es doch nach den Einstellungen im Grub etc.. bzw. fehlenden FW Treibern nicht geht.

    Dann kann man nur die verschiedenen Ausgabemöglichkeiten testen.


    Da im Grub z.B. DP-3 steht und kann man ja mal andere EInstellung am Speakertest ausprobieren. Dann sieht man z.B. im Ausgabe-Plugin am VDR gefordert wird.


    Teste doch mal nach Beendigung vom VDR


    speaker-test -c2 -D hdmi:1

    oder


    Code
    1. speaker-test -t wav -c2 -D hdmi:1


    speaker-test -c 2 -r 48000 -D hw:1,7


    speaker-test -c 2 -r 48000 -D hw:1,3