yavdr experimental für Ubuntu 20.04 (yavdr ansible @ focal)

im setup menu von softhdvaapi - video - gamma

ansonsten in der setup.conf

softhdvaapi.Gamma = 100

Zitat von joachim-h

Apropos und Off-Topic: Wie ist denn der derzeitige Stand bei Permashift? Gibt es eine Distribution, die den Patch hat und sind Patch und Plugin stabil?

Es gibt für den VDR 2.4.x bislang nur einen ungetesteteten Patch, am Plugin hat sich seit 2015 nichts mehr getan.

Ich habe gerade einen VDR mit zapcockpit, naludump und menuselection für focal gebaut (https://launchpad.net/~seahawk…r-2.4.1-patches/+packages), morgen kümmere ich mich um die Plugins. Den permashift-Patch habe ich erst mal weggelassen, weil der in Kombination mit den oben genannten Patches weitere Anpassungen benötigt - ich will erst mal wissen, ob die neu hinzugefügten Patches reibungslos funktionieren, bevor ich den anpasse.

Zitat von seahawk1986

Ich habe gerade einen VDR mit zapcockpit, naludump und menuselection für focal gebaut (https://launchpad.net/~seahawk…r-2.4.1-patches/+packages), morgen kümmere ich mich um die Plugins.

Sehr cool...! Allerdings ist noch einiges rot im Repo - scheint wohl doch noch ein wenig Arbeit vor Dir zu liegen . Wenn die Plugins durch sind, bin ich direkt dabei und teste. Danke Dir schonmal jetzt für die Anhebung des WAF meiner aktuellen Umgebung

Zitat von seahawk1986

Ich habe gerade einen VDR mit zapcockpit, naludump und menuselection für focal gebaut

Der menuselection-Patch hat mir beim yaVDR-bionic noch gefehlt! Super das der endlich dabei ist!

Da werde ich kommende Woche wohl mal eine Partition frei machen, um das neue vaVDR-focal zu testen.

Da jetzt nahezu alle Pakete vorhanden sind, hab ich mal eben die Repo's gewechselt und aktualisiert. Ein erstes Fazit: Läuft und sieht gut aus...!

Ja, da hatte ich vergessen ppa:yavdr/experimental-main als PPA für Build-Dependencies hinzuzufügen, daher sind da ein paar mehr fehlgeschlagen als die Pakete, die von einem erfolgreich gebauten Skindesigner abhängen.

Mein Ziel ist ein Yavdr mit 3840x2160 mit 50 Hz mit möglichst guter Qualität (und später auch mit HDR). Ich nutze yavdr ansible @ focal, Intel UHD 630 Grafik mit einem 4k-Monitor (max.60 Hz). Maßstab wäre eine hochwertige Darstellung des Senders "SES UHD Demo Channel". Unter Kodi per VNSI bin ich mit der Qualität schon recht zufrieden (3840x2160_50). Mit softhddevice läuft es bei gleicher Auflösung nicht ganz flüssig. Mit softhdvaapi gibt es stärkere Aussetzer. Hier sollte es doch eigentlich recht glatt laufen. DRI 3 ist aktiv. Ich habe den Eindruck, dass die Hardware-Beschleunigung nicht richtig funktioniert. Ich habe mal die Syslog und einige Ausgaben hinzugefügt. Ein Test mit Nvidia Hardware verlief ähnlich. Hat jemand vielleicht eine Idee, wo das Problem liegen könnte?

MfG. Steato

root@yavdr2020f:~# dpkg -l | grep -i mesa

ii libegl-mesa0:amd64 20.0.4-2ubuntu1 amd64 free implementation of the EGL API -- Mesa vendor library

ii libgl1-mesa-dri:amd64 20.0.4-2ubuntu1 amd64 free implementation of the OpenGL API -- DRI modules

ii libgl1-mesa-glx:amd64 20.0.4-2ubuntu1 amd64 transitional dummy package

ii libglapi-mesa:amd64 20.0.4-2ubuntu1 amd64 free implementation of the GL API -- shared library

ii libglu1-mesa:amd64 9.0.1-1build1 amd64 Mesa OpenGL utility library (GLU)

ii libglx-mesa0:amd64 20.0.4-2ubuntu1 amd64 free implementation of the OpenGL API -- GLX vendor library

ii mesa-utils 8.4.0-1build1 amd64 Miscellaneous Mesa GL utilities

ii mesa-vulkan-drivers:amd64 20.0.4-2ubuntu1 amd64 Mesa Vulkan graphics drivers

root@yavdr2020f:~# dpkg -l | grep -i placebo

ii libplacebo29:amd64 1:1.29.1-1yavdr0~focal amd64 GPU-accelerated video/image rendering primitives (shared library)

ii libplacebo42:amd64 1:2.43.0+git20200424-8-e7b3606-0yavdr0~focal amd64 GPU-accelerated video/image rendering primitives (shared library)

root@yavdr2020f:~# dpkg -l | grep -i vulkan

ii libvulkan1:amd64 1.2.131.2-1 amd64 Vulkan loader library

ii mesa-vulkan-drivers:amd64 20.0.4-2ubuntu1 amd64 Mesa Vulkan graphics drivers

root@yavdr2020f:~# lspci | grep VGA

00:02.0 VGA compatible controller: Intel Corporation 8th Gen Core Processor Gaussian Mixture Model

[1]+ Exit 127 ii i965-va-driver-shaders:amd64 2.4.0-1build1 amd64 VAAPI driver for Intel G45

seahawk1986 - danke für die neuen Pakete mit u.A. Zapcockpit patch - läuft bei mir seit einigen Stunden einwandfrei! Damit ist mein eigenes Repo jetzt wieder obsolet

Hey Seahwak,

Vielen Dank für Deine Mühe und die neuen Pakete. Habe mir das Repo auch gerade installiert und der neue Verlauf einwandfrei bei mir.

Joachim

Hmmm, ich hoffe Ihr steinigt mich jetzt nicht.

Ich tät gerne mein yavdr-ansible von Bionic auf Focal upgraden.

Wie das geht findet man ja auf diversen Seiten im Netz. Aber wie schaut es mit dem yavdr-Unterbau aus. Kann man das dist-upgrade gefahrlos machen oder ist eine Neuinstallation von Focal zwingend erforderlich?

Hat das Upgrade schon jemand gemacht und wie sind die Erfahrungen?

Danke vorab

Matthias

steato Du hast noch einen 2. Screen auf :0.1 auf welchen Screen soll das Bild denn rauskommen ? Versuch doch mal alle Plugins abzuschalten ausser softhdvaapi. Dann sieht man besser was passiert. Und wenn du kannst dann übersetze das Plugin mal mit DEBUG.

@jojo61, die Wiedergabe erfolgt über DisplayPort. Ein 2. Monitor ist nicht angeschlossen - sind ev. Relikte aus einem Versuch über HDMI. Bei der Syslog in der Anlage waren nur softhdvaapi und dbus2vdr aktiviert. Ohne dbus2vdr startet der VDR nicht.

Ok ich sehe das du auf das ZDF geschaltet hast und ein Stream gekommen ist. Hattest du da ein Bild ? Dann hast du auf UHD SES geschaltet und auch da kam ein Stream. War da auch ein Bild ? Zumindest hat er da nach 8 Sekunden gesagt das der Buffer übergelaufen ist.

Falls du placebo hast dann konfiguriere in den Settings mal bilinear als scaler für UHD.

Um mehr sagen zu können müsste das PLugin mit DEBUG übersetzt werden. Die CPU mit der UHD Graka sollte 4k schaffen.

Hallo,

ich wollte auch gerade auf das neue Ubuntu umstellen.

Die Installation bricht nach der Einrichtung der Partitionen immer ab.

Ich sehe im Log diesen Fehler:

An error occured handling 'partition-sdb1': ValueError - dictionary update sequence element #3 has length 1; 2 is required

Kann aber nichts damit anfangen.

Hat jemand eine Idee?

Kannst du mal die Ausgabe von sfdisk --dump /dev/sdb posten (ggf. von einer Ubuntu 20.04 Desktop Live-CD booten, wenn du keine Konsole beim Server-Installer bekommst)?

Ich hab hier noch ein Problem mit dem osd2web Plugin - ich bekomme seit dem neuen Repo regelmäßig Segfaults und hab jetzt mal gesucht (und glaub ich auch gefunden).

Du hast die "neue" Version gegen die libwebsockets15 aus dem Universe-Repo gebaut (V 3.2.1-3). Da ich bei mir aber außerdem noch das yavdr experimental-main PPA eingebunden habe, zieht er von dort die lib in V 3.2.0-1:

root@yavdr:/var/lib/vdr# apt policy libwebsockets15
libwebsockets15:
  Installiert:           1:3.2.0-1yavdr0~focal
  Installationskandidat: 1:3.2.0-1yavdr0~focal
  Versionstabelle:
 *** 1:3.2.0-1yavdr0~focal 500
        500 http://ppa.launchpad.net/yavdr/experimental-main/ubuntu focal/main amd64 Packages
        100 /var/lib/dpkg/status
     3.2.1-3 500
        500 http://de.archive.ubuntu.com/ubuntu focal/universe amd64 Packages
root@yavdr:/var/lib/vdr#

Wird das dort noch bereinigt oder was wäre aus Deiner Sicht die korrekte Vorgehensweise für mich?

Das dürfte eine Folge davon sein, dass ich experimental-main erst nachträglich als PPA mit Abhängigkeiten für das neue PPA eingebunden habe - ich denke das beste ist, wenn ich die Version in experimental-main aktualisiere und das osd2web-Plugin noch mal neu dagegen bauen lasse. Ich baue bei der Gelegeneit gleich mal einen Patch ein, der verhindert, dass er beim Parsen der JSON-Daten, die über den Websocket kommen, über die Buffergrenze hinaus liest, weil die falsche Methode der libjansson genutzt wird, die einen null-terminierten String erwartet.

Perfekt...! Pakete sind da. Ich denke, die segfaults haben sich damit erledigt

Vielen Dank für die schnelle Reaktion - toll wie Du das jedes Mal so umsetzt. Wenn das nur überall so klappen würde

label: dos
label-id: 0xd8c5d874
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=    78123008, type=83, bootable
/dev/sda2 : start=    78125056, size=    78125056, type=83
/dev/sda3 : start=   156250112, size=    78190592, type=83

label: dos
label-id: 0x0007ca9c
device: /dev/sdb
unit: sectors

/dev/sdb1 : start=        2048, size=    29294592, type=83, bootable
/dev/sdb2 : start=    29296640, size=    28682240, type=83
/dev/sdb3 : start=    57985022, size=  2872291330, type=5
/dev/sdb5 : start=  2927134720, size=     3141632, type=82
/dev/sdb6 : start=    57985024, size=    29294592, type=83
/dev/sdb7 : start=    87281664, size=  2839851008, type=83

sda ist eine SSD, auf sda1 ist 18.04. auf sda2 wollte ich 20.04 installieren, sda3 noch nicht verwendet.

sdb war früher alleine, 2 alte Installationen auf sdb1 und sdb2, sdb6 ist /home, sdb7 ist /srv.

Habe aber auch schon beide abgezogen und eine andere Festplatte probiert. Im BIOS den Modus von AHCI auf SATA umstellen hat auch nichts geändert.

Ich denke das ist ein Problem von curtin - die Funktion, die die Ausgabe von sfdisk parst, geht davon aus, dass da durch Kommata von einander getrennte Werte-Paare im Stil key=value vorkommen, keine einzelnen Flags ohne Wert. Auch wenn heutzutage vermutlich kaum jemand mehr ernsthafte Server mit MBR-Boot betreibt, ist das ein blöder Bug, den man melden sollte.

Als Würgaround könntest du mal versuchen das bootable-Flag von der Partition zu entfernen (in gparted kann man das recht bequem mit GUI machen) und dann den Installer laufen zu lassen und es später ggf. wieder hinzuzufügen.