Welches Motherboard für neuen VDR?

  • Ich bin bzgl. Mainboard nun auf diesen Thread gestoßen: Geeignetes Mainboard für einen Neubau


    Der user Grillbert schildert dort seine Erfahrungen mit einer Installation (ubuntu, yavdr). Ganz einfach scheint es nicht zu gehen - also nicht einfach mal die HDD ins neue System stecken. Trotzdem hab ich auch ein neues Mainboard, allerdings von ASUS bestellt (J3455M-E). Mal sehen ..


    Gruß!

  • Hallo,


    ich habe auch gerade einen J3455 (von Asrock, mini-itx) verbaut.
    Verwendet habe ich dabei Ubuntu 16.10 (wegen dem neueren Kernel), das PPA https://launchpad.net/~nicola-…a/+archive/ubuntu/desktop für ffmpeg 3.2 und neuere Intel-Treiber und zusätzlich softhddevice von https://github.com/pesintta/vd…hddevice/tree/vpp_support.


    Damit funktionierte auf Anhieb fast alles. Mal abgesehen von pulseaudio, dessen autostart ich deaktivieren musste, damit der Sound über HDMI beim reboot nicht immer stumm geschaltet wurde.


    Zabrimus

  • das PPA https://launchpad.net/~nicola-onorata/+a…/ubuntu/desktop für ffmpeg 3.2 und neuere Intel-Treiber und zusätzlich softhddevice von https://github.com/pesintta/vdr-plugin-s…ree/vpp_support.

    Hast Du Softhddevice aus dem Pesintta-Zweig patchen müssen, dass es unter ffmpeg 3.2 kompiliert hat?


    Danke und Gruß
    Stefan

  • Hast Du Softhddevice aus dem Pesintta-Zweig patchen müssen, dass es unter ffmpeg 3.2 kompiliert hat?


    Mir war nicht klar, das etwas gepachted hätte werden müssen sollen.
    Nein. Ich habe es mir einfach gemacht: git clone und compile.
    Ich habe auch den Zweig von jojo61 (auch ohne Patch) ausprobiert, aber da hatte ich das Problem, daß ein Bild erst nach einem Kanalwechsel zu sehen war.


    Zabrimus

  • 447377 & Zambrinus


    Die Kernel der Ubuntu Zwischenversionen gibt es auch immer früher oder später für die LTS Versionen im Archiv, für Xenial LTS diesmal früher mit dem Paket linux-generic-hwe-16.04-edge oder auch linux-lowlatency-hwe-16.04-edge. Das installiert aktuell den 4.8er Kernel von Yakkete (16.10) und wahrscheinlich später auch nahtlos den Zesty Kernel.


    ffmpeg-3.2.2 gibt es als Ubuntu Package im Zesty Archiv und lässt sich für Xenial backport'en. Wer sich das selbst nicht zutraut, kann sich einen Backport für Xenial von hier holen: https://launchpad.net/~fnu/+archive/ubuntu/main-testing-fnu


    Generell benötigt der VPP Zweig von pesintta (und auch rofafor) kein ffmpeg-3.2.2, da reicht 2.8.10 aus dem Xenial Archiv. ffmpeg-3.2.2 wird nur benötigt wenn HEVC von "jojo61" ins Spiel kommt. rofafor, welcher pesintta unterstützt, hat hier vor einigen Tagen die Zusammenführung des VPP Zweigs mit den HEVC Erweiterungen von "jojo61" vorgestellt und um Tests gebeten:


    => [Announce] VA-API/VPP Support for vdr-plugin-softhddevice
    => Git: https://github.com/rofafor/vdr…ice/tree/vpp_support_hevc


    Bitte aber auch dort antworten.


    Regards
    fnu

    HowTo: APT pinning

    2 Mal editiert, zuletzt von fnu ()

  • Hallo fnu,


    danke für Denen Beitrag. Ich hatte zwischen den Jahren einen Intel-vaapi-VDR aufgebaut und musste den Pesintta-Zweig wegen ffmpeg 3.2 (Standard bei Suse 42.2) patchen. Den HVEC-Zweig von jojo61 hatte ich inzwischen gesehen, aber noch nicht getestet.
    Ich fraget halt, ...nicht dass der originale Pesintta-Zweig inzwischen angepasst wurde und ich hab's nicht mitbekommen... :sleep


    Stefan

  • Naja, ein Blick auf die (letzten) Commits beantwortet die Frage leicht ... :


    - https://github.com/pesintta/vd…evice/commits/vpp_support
    - https://github.com/rofafor/vdr…evice/commits/vpp_support


    Es ist auf ffmpeg3 angepasst ...


    Überlege mir gerade ob wir nicht besser einen eigenen Thread zum J3455 aufmachen.


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Naja, ein Blick auf die (letzten) Commits beantwortet die Frage leicht ... :

    Sag doch gleich, dass ich auf "commits" klicken muss, um die Änderungen zu sehen... - wieder was gelernt!


    Vielen Dank
    Stefan

  • Ähm, wie sollte man sonst mitbekommen was geändert wurde? Commits/Changesets sind überhaupt die Existenzgrundlage einer Versionsverwaltung wie cvs,hg oder git ... :rolleyes:


    Regards
    fnu

    HowTo: APT pinning

  • Um hier auch noch was Sinnvolles bzw. der Frage entsprechendes beizutragen:
    Ich hatte mir vor einigen Monaten auch mal ein Asrock-MB zugelegt (N3710-ITX). Das Board ist sehr genügsam im Verbrauch (ich berichtete hier), allerdings nicht im ausgeschalteten Zustand. Mit einer korrekten Bios-Einstellung war's das dann auch (ging von 2,5 auf 0,5 Watt runter). Aber: sobald wol aktiviert ist oder ein Timer angelegt ist, dann sind's wieder 2,5 W. Egal ob mit Pico PSU oder be.quiet-Netzteil. X( Also kommt mir vorerst kein Asrock-Board mehr ins Haus.


    Mit meinen Asus-Boards waren's immer 0,3 - 0,5 W im ausgeschalteten Zustand. Auch wenn mir die Hinweise von fnu auf MSI-Eco- Boards sehr gefielen, fielen meine Entscheidungen immer auf Asus. Ausschlaggebend war die kurze Bootzeit, was mit MSI wohl nicht zu erreichen war/ ist.


    Ich hatte neulich ein Asus H110M-D + Intel G3900 aufgebaut, das auch sehr genügsam und schnell läuft. Der Verbrauch damit liegt etwa 4 W unter dem akt. Wohnzimmer-VDR (siehe Signatur) - bei gleicher Ausstattung (nvidia + graphtft per Intel usw.). :tup


    Ggf. ist das Asus J3455M eine interessante Alternative. Ich hab's jedoch noch nicht getestet.


    Stefan

  • Ich hatte mir vor einigen Monaten auch mal ein Asrock-MB zugelegt (N3710-ITX). Das Board ist sehr genügsam im Verbrauch (ich berichtete hier), allerdings nicht im ausgeschalteten Zustand. Mit einer korrekten Bios-Einstellung war's das dann auch (ging von 2,5 auf 0,5 Watt runter).


    Hi Stefan,


    habe derzeit das Board http://www.asrock.com/mb/Intel…C-ITX/?cat=Specifications zum testen hier, und habe das gleiche Verhalten beobachtet. Welche Einstellung hast Du im BIOS verändert, dass das Board im ausgeschaltetem Zustand runter auf 0,5 Watt geht? Vielleicht funktioniert das dann bei mir auch ...


    Danke schon mal im Voraus.


    Gruß
    Neo


  • siehe...
    http://www.vdr-portal.de/board…t/?highlight=#post1277590


    Gruß
    Stefan


  • Hi Stefan,


    danke. Hab es getestet, und es zeigt das gleiche Verhalten wie bei Dir mit aktuellem BIOS (1.30) ... 0.5 vs. 2.5 Watt im Standby. Auch das Aktivieren eines Wake-Up-Events lässt den Verbrauch im Standby wieder auf 2.5 Watt ansteigen. Ansonsten ist mir nur noch aufgefallen, dass das Board unter softhddevice (Johns aktuelle git Version) etwas mehr Leistung zieht (13 - 16 Watt), als unter KODI 16.1 (10 - 13 Watt). Idle liegt so zwischen 8.7 und 9.3 Watt (CPU Fast Mode).


    Konfiguration:
    OS: openSUSE Tumbleweed x86 (aktuell)
    SSD: Transcend SSD370 32GB
    RAM: 1 x 4GB DDR3L-1600 @ 1.35 Volt
    Video über HDMI
    Ton über Klinke
    USB1: Tastatur
    USB2: Maus
    USB3: FLIRC
    USB4: Strom für USB-Boxen via Klinke


    Ich hätte noch eine Frage zu HPET unter Linux; soll(te) ich besser dafür einen neuen Thread aufmachen?


    Gruß
    Neo

  • Ich hätte noch eine Frage zu HPET unter Linux; soll(te) ich besser dafür einen neuen Thread aufmachen?

    Ja, bitte, das wir nicht noch weiter abdriften und wird in einem neuen Thread auch besser wahrgenommen.


    Regards
    fnu

    HowTo: APT pinning

  • Ich habe jetzt das J3455M hier und für einen ersten Test mal eine Platte mit einem älteren System (SUSE 11.4) angesteckt.
    Das Booten geht dermaßen langsam, daß man es fast nicht abwarten kann. Wenn er dann mal gebootet hat läuft eine kleine Perl-Testschleife

    Code
    while ($i < 999999999) { $i++; $x = sqrt($i); }


    genauso schnell wie auf einen vergleichbaren anderen Rechner.


    Gut, liegt vielleicht an zu altem Kernel bzw. Treibern. Also hab ich mir openSUSE Leap 42.2 auf einen USB-Stick geladen und von dort gebootet. Geht genauso langsam. Wenn ich nach längeren Warten in die Installationsoberfläche komme, wo es einen Mauscursor gibt, dann sehe ich, daß der Cursor beim Bewegen der Maus immer wieder mal stehenbleibt. Er bewegt sich dann wieder einige Sekunden ganz normal und plötzlich "stockt" er wieder für mehrere Sekunden.


    Das BIOS-Setup des Boards (inklusive Mausbedienung) funktioniert einwandfrei.
    UEFI hab ich upgedatet und CSM eingeschaltet.
    Folgende Meldungen kommen beim Booten:


    mce: [Hardware Error]: Machine check events logged


    GHES: HEST is not enabled


    Anscheinend ist das Board wohl "zu neu" für Linux.
    Hat jemand eine Idee, was ich noch versuchen könnte?
    Wäre schade um das Board, denn es macht ansonsten einen tollen Eindruck. Der CPU-Kühlkörper wird kaum warm.


    Klaus

  • Anscheinend ist das Board wohl "zu neu" für Linux.
    Hat jemand eine Idee, was ich noch versuchen könnte?

    Hast du schon das aktuellste BIOS aufgespielt? Da gab es wohl Verbesserungen in Sachen Linux-Kompatiblität und ein Microcode-Update für die CPU: http://www.asrock.com/mb/Intel/J3455M/?cat=Download&os=BIOS


    Wenn ich das richtig sehe, ist OpenSuSE Leap 42.2 mit dem Kernel 4.4 unterwegs, aktuell ist der Kernel 4.9 - falls das mit dem BIOS-Update allein nicht hilft, könnte man mal einen Versuch mit Arch Linux wagen, dann hat man eine ausreichend aktuelle Basis für Experimente mit neuer Hardware.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das BIOS hab ich auf Version 1.20 upgedatet, hat aber keinen Unterschied gemacht.


    Ich lasse jetzt mal eine Default-Installation durchlaufen (dürfte einige Stunden dauern) und schau dann, ob es letztendlich dann doch normal läuft. Wenn nicht muß ich wohl mal Arch Linux probieren...


    Klaus

  • @Klaus
    Ich hatte auch zwei Jahre die FF von Technotrend drin. Aber im Gegebsatz zu der damaligen SD Lösung ging/geht damit werder mplayerplugin noch kodi. Das fand ich alles extrem schade. ich schaue nun seit drei Jahren mit EasyVDR über die normale Intelchipsatzgrafik und vaapi. Und das geht gut! Dabei handelt es sich schon um eine definitiv ä#lteren Intelchipo. DIe neuen müssten das noch besser können (Gigabyte Z97X).

  • kls


    Ja, das gibt es immer wieder bei Intel, irgendwie schaffen es die nötigen Änderungen langsam in den Kernel ...


    könnte man mal einen Versuch mit Arch Linux wagen

    Aktuellere Kernel (4.8/4.9) zu Testzwecken gibt es vmtl. für jede Linux Distro, nicht nur Arch ... :rolleyes: ... für gentoo, Debian, Ubuntu, ..., sowie OpenSuse:


    - http://download.opensuse.org/r…:/stable/standard/x86_64/


    Regards
    fnu

    HowTo: APT pinning

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!