[yavdr_ansible] diverse Kleinigkeiten

  • Es gibt in den Anzeigen-Einstellungen von KODI eine Whitelist (vgl. https://github.com/xbmc/xbmc/pull/13274 und https://github.com/xbmc/xbmc/pull/13899) , mit der man die Modi setzen kann, die für das Wechseln von Auflösung und Bildwiederholrate genutzt werden sollen. Mit der von yavdr-ansible erzeugten xorg.conf werden mir da alle Modi mit den dazu gehörigen Refreshrates angezeigt.


    Das automatische Wechseln von Auflösung/Refreshrate beim Start eines Videos scheint aktuell nicht immer zuverlässig zu funktionieren, wenn das Videoformat nicht 100% passt (in den Einstellungen das Debug-Logging für alles Player-, Audio- und Video-bezogene aktivieren, dann sieht man was er bei der Wiedergabe macht).


    Bei 1920x1080p24 Material (wie man es von einer Blu-Ray bekommen würde) klappt es auf meinem System:

    Code
    12:50:54.822 T:139675372963584   DEBUG: CRenderManager::Configure - change configuration. 1920x1080. display: 1920x1080. framerate: 23.98.
    [...]
    12:50:54.923 T:139677681952960   DEBUG: Trying to find exact refresh rate
    12:50:54.923 T:139677681952960   DEBUG: Matched exact whitelisted Resolution DP-0: 1920x1080 @ 23.98Hz (34)
    12:50:54.923 T:139677681952960  NOTICE: Display resolution ADJUST : DP-0: 1920x1080 @ 23.98Hz (34) (weight: 0.000)


    Bei Sintel.2010.1080p.mkv (https://durian.blender.org/download/), bei dem es IIRC mit KODI 17 ohne Probleme ging automatisch auf 1920x1080p24 umzuschalten, klappt es vermutlich wegen der krummen Videoauflösung nicht:

    Code
    12:30:37.016 T:139625611908864   DEBUG: CRenderManager::Configure - change configuration. 1920x818. display: 1920x818. framerate: 24.00.
    [...]
    12:30:37.445 T:139627478067392   DEBUG: Trying to find exact refresh rate
    12:30:37.446 T:139627478067392   DEBUG: No exact whitelisted resolution matched, trying double refresh rate
    12:30:37.446 T:139627478067392   DEBUG: No double refresh rate whitelisted resolution matched, trying current resolution
    12:30:37.447 T:139627478067392   DEBUG: No larger whitelisted resolution matched, trying current resolution with double refreshrate
    12:30:37.447 T:139627478067392   DEBUG: No whitelisted resolution matched
    12:30:37.447 T:139627478067392  NOTICE: Display resolution ADJUST : 1920x1080@ 50.00 - Full Screen (16) (weight: -0.000)

    In dem Fall kann ich über den Eintrag in den Wiedergabe-Optionen des Players den gewünschten Mode von Hand setzen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Vielen Dank, genau das war es. Unter Settings > System > Display > Whitelist habe ich jetzt mal testweise alles aktiviert (war bisher alles aus) und schon schaltet der TV brav auf 24Hz um. Die Familie freut sich!


    Cheers,

    Ole

  • Das mit dem nicht gefundenen Video-Modus beim Start kann ich reproduzieren, wenn ich im UEFI die Boot-Optimierung für die Grafik einschalte, also die GPU vor dem Booten des Betriebssystems nicht initialisiert wird. Wenn man was vom Boot-Vorgang sehen will, sollte man die Option also deaktvieren.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das mag sein, aber ich habe hier ein BIOS-Boot, kein UEFI.


    Bin auch gerade noch auf ein sehr eigenartiges Problem gestoßen. Ich habe Kodi durch die aktuelle nightly der Verion 18 ersetzt. Laut apt ist es auch die aktuelle Version aus dem GIT (20180529), starte ich aber Kodi finde ich in den Systeminformationen die Version 201204xx...


    Die binaries sind auch tatsächlich vom April 2012.


    Kann das jemand bestätigen?


    Cheers,

    Ole

  • Ja, das wurde beim Update auf die 18er automatisch entfernt.


    Code
    root@yavdr:~# apt-cache policy kodi-bin
    kodi-bin:
      Installiert:           (keine)
      Installationskandidat: 2:17.6+dfsg1-1ubuntu1
      Versionstabelle:
         2:17.6+dfsg1-1ubuntu1 500
            500 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

    Momentan sind diese Versionen (kodi & kodi-x11) installiert



    Aber das kodi.log sagt 21:05:52.455 T:140225685013824  NOTICE: Starting Kodi (18.0-ALPHA2 Git:20121104-b9a7189). Platform: Linux x86 64-bit

    und das hier wären die Binaries.

    Code
    root@yavdr:~# ll /usr/bin/kodi*
    -rwxr-xr-x 1 root root 6709 Nov  4  2012 /usr/bin/kodi*
    -rwxr-xr-x 1 root root 2592 Nov  4  2012 /usr/bin/kodi-send*
    -rwxr-xr-x 1 root root 1825 Nov  4  2012 /usr/bin/kodi-standalone*


    Cheers,

    Ole

  • Also das ist definitv im Paket kodi-x11 schief



    Cheers,

    Ole

  • Habe gerade die Info bekommen, dass die Serverzeit auf dem zuständigen buildserver nicht stimmt. Die binaries passen so.


    Cheers,

    Ole

  • So, der Splashscreen ist jetzt auch bei mir funktional.


    Hintergrund ist, dass die Serverinstallation von Ubuntu 18.04 eine Datei /etc/default/grub.d/50-curtin-settings.cfg anlegt, welche den Inhalt von /etc/default/grub überschreibt (vgl. hier). Dort werden per default folgende Parameter gesetzt:


    Code
    GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity"
    GRUB_TERMINAL=console


    Das setzt natürlich grafisches Grub-Menü und Plymouth außer Gefecht. Beide Zeilen auskommentiert, die passende Auflösung für meinen Zweitbildschirm in /etc/default/grub eingetragen

    Code
    GRUB_GFXMODE=1920x1080x32
    GRUB_GFXPAYLOAD_LINUX=keep

    und ein beherztes sudo update-grub machen den Bootsplash dann funktional.


    Leider bootet mein System so schnell, dass ich den Splashscreen nur ganze zwei Sekunden zu Gesicht bekomme... :D

    Aber immerhin, keine Fehlermeldung mehr bzgl. nicht aktiviertem grafischen Modus im Grub.


    Cheers,

    Ole

  • Wie hast du den Ubuntu Server installiert (liegt das eventuell am neuen Subiquity Installer)?


    Ich habe bislang entweder das mini.iso oder den Ubuntu Server Alternative Installer genommen (http://cdimage.ubuntu.com/releases/18.04/release/), weil der neue unpraktisch ist, wenn man bestehende Partitionen weiter verwenden will:

    If you require advanced networking and storage features such as; LVM, RAID, multipath, vlans, bonds, or re-using existing partitions, you will want to continue to use the alternate installer.

    Bei der Rollenauswahl habe ich dann höchstens den OpenSSH-Server als Installationsoption ausgewählt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ja, das kommt definitiv vom neuen Installer, den ich bei meiner Installation verwendet habe. Ich benötige die Features des alternativen Installers eigentlich nicht, daher wollte ich mal den Neuen testen. Das fehlende LVM ist mir leider erst hinterher aufgefallen, bei meiner relativ grßen SSD für das System ist aber auch das zu ertragen.


    Cheers,

    Ole

  • Ich habe die in [yavdr_ansible] diverse Kleinigkeiten angesprochenen Änderungen mal eingebaut: https://github.com/yavdr/yavdr…5449435e4a764a108c9e16eec - beim Fußball fällt das mit den Mikrorucklern wirklich störend auf.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich grabe diese Thread nochmal aus, da sich mir gerade folgende Frage stellt:


    Mein Atric USB hat sich (wohl aufgrund der anhaltenden Hitzewelle ;) ) verabschiedet. Jetzt habe ich hier noch einen FLIRC USB 2nd Gen.

    rumliegen, den ich als Ersatz ranziehen würde. Wie muss ich hier vorgehen, um die Anpassungen entsprechend durchzudrücken?


    Der momentane Stand ist, Harmony 350 mit KLS 1.1 Profil, Atric USB im lirc als /dev/irman.


    Zugegebenermaßen bin ich, was das Thema FB/lirc/uinput usw. angeht, nicht wirklich bewandert. :saint:


    Für zielführende Tips bin ich sehr dankbar.


    Cheers,

    Ole

  • Wie muss ich hier vorgehen, um die Anpassungen entsprechend durchzudrücken?

    Du brauchst eine udev-Regel, die das Attribut ENV{eventlircd_enable}="true" setzt, dann sollte eventlircd sich das Input Device greifen.

    Am besten schaust du mit sudo evtest nach, welchen Pfad das Input Device hat und fragst dann mit udevadm info --query=all --name=/dev/input/eventX ab, anhand welcher udev-Attribute man es identifizieren kann.


    Wenn die Tasten noch nicht passen (die Konfigurationssoftware sieht auf den ersten Blick nicht so aus, als ob man das yaVDR-Schema direkt nutzen kann, weil die HID Consumer Keys fehlen), kannst du zusätzlich noch eine Keymap mit ENV{eventlircd_evmap}="flirc.evmap" übergeben, dies als /etc/eventlircd.d/flirc.evmap vorhanden sein muss und die Tastennamen für eventlircd zuordnet (Übersicht der Tastennamen und Beschreibung der evmap-Syntax).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Vielen Dank seahawk1986 und beinhart, das werde ich dann mal demnächst angehen und testen.

    Muss ich dann im lirc noch etwas ändern/deaktivieren? Momentan beschwert sich lirc, dass /dev/irman

    nicht mehr vorhanden ist.


    Cheers,

    Ole

  • Muss ich dann im lirc noch etwas ändern/deaktivieren?

    Wenn du lirc nicht mehr brauchst, kannst du es abschalten:

    Code
    sudo systemctl disable lircd.service
    sudo systemctl stop lircd.service

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • So, habe momentan eine Logitech Tastatur am VDR und lediglich XKeySym.* Einträge in der remote.conf (die yaVDR defaults),

    lircd.service ist deaktiviert - die Steuerung per Tastatur sollte ja trotzdem möglich sein, wenn ich das richtig verstehe.


    Allerdings: Tastendrücke kommen nicht am VDR an.


    evtest listet mir diese Devices:


    Und ein evtest auf Device 2 (Logitech K830) produziert auch Output:


    Cheers,

    Ole

    Einmal editiert, zuletzt von OleS ()

  • Interessant, ich konnte das gerade mit einer Logitech K340 nachstellen - interessanterweise hat die Tastatur funktioniert, nachdem ich xev mit xev -d :0 gestartet hatte.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

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