Beiträge von lostinspc

    Damit ist das Problem erst mal gelöst, aber irgend wann wird es kommen, ich hoffe, dass sich dann jemand findet, der softhddevice anpasst.


    Verstehe ich nicht so ganz?


    Es ( https://github.com/pesintta/vdr-plugin-softhddevice ) ist doch angepasst und läuft.

    Moin,

    Ich bin auf Kernel 4.14.x gespannt. Weißt du ab welchem Kernel genau die Last so angestiegen ist? Oder bist du gleich von 4.8 auf 4.13?

    Auf 4.14 bin ich auch gespannt (befürchtet aber, das der an dieser Ecke nichts ändert).


    Reingekommen ist das meiner Erinnerung nach mit 4.12 oder 4.13. Ich habe das nach dem Hardwarewechsel auf den NUC festgestellt, das war im Sommer.


    Ist mM ja prinzipiell auch kein Problem.

    Die prozentuale CPU Auslastung ist bei mir "idle", der Lüfter bleibt aus, das System ist weiterhin voll responsiv.

    Irgendwie aber trotzdem unschön und war ja vorher auch nicht :-)


    Peter

    MarMic

    Hab jetzt den modesetting Treiber am laufen. Sieht soweit nicht schlecht aus, die load ist (mit 4.13 kernel) aber nur leicht gesunken, liegt jetzt so zwischen 1,65 und 1,8, also so ca. 10 - 20% niedriger als vorher.

    Das Kernproblem mit dem 4.13 kernel behebt er also nicht.

    Ich lass ihn trotzdem mal drin ...

    Hast du nur den Kernel hochgezogen oder dabei auch libva/vaapi und was da noch so rein spielt angefasst?

    Nutzt du Intel als Treiber oder modesetting?

    Hi,


    der Rest des Systems inkl. libva usw. ist auf dem neusten (arch stable) Stand, das ist ziemlich aktuell.


    Das mit dem modesetting-driver ist ein interessanter Hinweis, kannte ich noch gar nicht, ich dachte man müsste zwingend xf86-video-intel verwenden.

    Habe mal kurz drüber gelesen, werde ich auf jeden Fall heute Abend ausprobieren.

    Ob es in dem speziellen Fall Besserung bringt ... man wird sehen.


    VG Peter

    MarMic

    Zufrieden bin ich nicht. Ich habe ein Lenovo T430 benutzt für die Tests. Mir gefällt die Last aber überhaupt nicht. Verstehe aber noch nicht woher die kommt

    Die hohe load bei intel vaapi ist bei mir ein Problem mit neuen Kernelversionen.


    Unter arch mit kernel 4.8 lts habe ich eine load von 0,1 bis 0,2 (SD oder HD Livebild, NUC siehe Sig).


    Mit dem aktuellen Kernel 4.13 habe ich mit ansonsten unveränderter config eine Load von >= 2

    Ansonsten verhält sich das System aber nicht anders, die hohe load stellt kein merkbares Problem dar.


    Habe auch schon mal kurz versucht, mit strace etwas Licht in die Sache zu bringen, war aber auf die Schnelle nicht so richtig erfolgreich.


    VG, Peter

    Beim NUC6CAYH muss man noch beachten, dass der keinen freien M.2 Slot für eine ssd hat, dort geht nur 2,5 SATA.


    HEVC habe ich mit dem NUC7i3BNH schon ausprobiert, geht problemlos auf der GPU (sowohl decodieren als auch encodieren).

    Speziell wenn GPU encodieren ein Thema ist, hat der i3 wohl deutlich mehr Dampf.

    Qualitativ ist man dabei natürlich eingeschränkt.


    Ich habe den i3 unter anderem deshalb genommen, weil ich für den Skindesigner noch etwas mehr Power brauchte, das scrollen durch die Aufnahmen war auf meinem alten Board mit Intel-Grafik (Asrock N3150M mit Braswell Celeron 3150) doch etwas zäh ....

    So was wie softhddev-openglosd gibt's ja für Intel Grafik leider nicht.

    Moin,


    Zitat


    Klingt interessant und da ich gerade auf der Suche nach neuer Hardware bin die Frage: "Taugt" der NUC7i3BNH was für VDR? Gehe mal davon aus. Grafikausgabe auch ok im Vergleich zu softhddevice mit Nvidia Grafik?

    Ich bin damit sehr zufrieden. Formfaktor und buildquality sind super.

    Eine tolle HW, wenn man nicht auf eingebaute Empfangskarten angewiesen ist.


    VDR-spezifisch:

    Grafik läuft völlig problemlos mit softhddev pesintta/rofafor. Das war aber mit meinem alten Board auch schon so.

    Ich sehe da bei meinen üblichen Sehgewohnheiten keinen Unterschied zu nvidia, pixelpeeper finden aber bestimmt was :-)


    Der Lüfter ist nicht zu hören, kann man mM im Bios bei idle auch ganz ausstellen.

    WOL und acpi-wakeup funktionieren selbstverständlich.

    Der ir-receiver kann problemlos als rc-core eingebunden werden.

    HDMI 2.0 port, CEC wird (tw. ?) onboard unterstützt.


    Da es mein Haupt-VDR ist, habe ich mir den Luxus einer relativ großen 2 TB ssd geleistet, der Rest geht aufs NAS.


    Wer es preisgünstiger mag, kann aber auch eine kleine M.2 ssd und eine Seagate Seagate FireCuda ST2000LX001 (ca. 90.-) und ggfs statt des NUC7i3BNH einen NUC6CAYH (bei Amazon für ca. 122.- EUR) nehmen.

    Tach,


    die aktuellen Intel NUC's (NUC6CAY, NUC7i[x]BN) sind mit einer s.g. Ring LED ausgestattet, die die Frontseite umschließt.

    Die Ring LED ist (auch) per Software ansteuerbar, es stehen verschiedene Farben und Effekte zur Verfügung.


    Ich habe ein kleines script zusammen getackert, das die Ring LED einschaltet, wenn der VDR aufnimmt.

    Ggfs. kann es ja noch jemand gebrauchen.


    Voraussetzung ist der entsprechende Kerneltreiber, den gibt es hier:

    https://github.com/milesp20/intel_nuc_led.git


    Das script muss zyklisch (z.B. alle 60 sec) aufgerufen werden und fragt über svdrp ab, ob eine Aufnahme läuft.

    Die Ring LED wird dann entsprechend ein oder ausgeschaltet.


    Ich habe den zyklischen Aufruf bei mir mit einer systemd timer unit realisiert, crontab geht auch.


    Peter


    1) Hat jemand Erfahrung mit BTRFS + Compress und weiß "Dos and Don'ts"?

    Lief hier bei mir ca. 2 Jahre auf einer 5 TB Platte unauffällig. Keine erhöhte CPU-Belastung, keine Verzögerung beim Springen o.ä.


    Der Nutzen ist aber wie schon geschrieben bei mpeg2 und h264 codierten files eher begrenzt und zumindest als ich das aufgesetzt habe gab es kein schönes Tool, das einem den durch Kompression gesparten Speicherplatz angezeigt hätte (und einen damit entsprechend vom Nutzen im vorgegebenen usecase überzeugt hätte)


    Habs deshalb beim HW-Umzug auf ein neues System auch nicht mehr aktiviert.


    Das Schöne an BTRFS compress ist allerdings, dass man es problemlos ein- und ausschalten kann, einfach fstab anpassen und neu booten. Wenn es ausgeschaltet wird, können komprimierte files nach wie vor gelesen werden.


    to_h264 vom jsffm bringt bei mpeg2 codierten Dateien ordentlich was, dauert allerdings dann je nach System auch ein paar Minuten pro Aufnahme das runterzurechnen.

    Tipp dazu: für den Parameter aaclib im Skript "aac" verwenden, das ist bei den neueren "normalen" ffmpeg-builds in den distro-repositorys schon dabei, das empfohlene "libfdk_aac" wegen copyright-Thematiken nicht.