[Marcus]

Hallo MLD-Entwickler und -User.

Ich habe hier ein paar zusammengefasste MLD 6.5 Bugs/Probleme, die mir beim Testen bisher aufgefallen sind. Vielleicht können wir zusammen ein paar dieser Probleme abstellen, damit die MLD noch besser wird.

Sytem:
Dell Wyse 3040, Atom x5 z8350 CPU, 2 GB RAM, 8 GB eMMC, Intel gen.8 iGPU, DVB kommt via streamdev-client und Aufnahmen per NFS. Verbindung zum Server via Ethernet, kein WLAN. Fernbedienung per FLIRC, also Tastatur-Events.

Die CPU ist vergleichsweise leistungschwach, vergleichbar mit einem RPi4, daher fällt das träge Verhalten hier vielleicht besonders deutlich auf. Ist halt kein Core i3/5/7. Dekodiert wird sowohl mpeg2 als auch h.264 auf der iGPU, das OSD und auch osdteletext werden per OpenGL gerendert. Beides per intel_gpu_top verifiziert und funktioniert, wie es soll.

Die Probleme im Einzelnen:

- Nach dem (Neu-)Start vom VDR (der APP) oder nach dem Booten braucht ein VDR-Prozess drei Minuten lang >100% und ein weiterer VDR-Prozess rund 25-30%. Ein Kern ist komplett am Anschlag. Nach drei Minuten fällt das schlagartig auf ca. 25-30%. Wenn der VDR-Prozess beendet wird, ist die CPU komplett idle auf allen Kernen, Load 0,01. Das liegt an epgsync (sync beim Start) und ist somit kein Bug der MLD.

- Scrollverhalten in Menüs, in denen der gesamte OSD-Inhalt verschoben werden muss, ist sehr ruckelig und langsam. MLD 5.4 läuft hier deutlich besser. Der Blitter, der genau sowas beschleunigen sollte, wird laut intel_gpu_top nicht benutzt. Upstreamproblem? Softhddevice oder OpenGL?

- Scrollverhalten in den VDR-Einstellungen "Sonstiges" ist sehr ruckelig und langsam. Ist es in MLD 5.4 aber auch. Upstreamproblem VDR? Wenn ja, was ist an diesem Menü so besonders?

- osdteletext ist extrem langsam. Seitenaufbau zwischen 2 - 4 Sekunden. Uhrzeit springt ebenfalls in diesem Intervall. Seiteneingaben brauchen 3x diese Zeit, da drei Ziffern eingegeben werden müssen. Also irgendwas zwischen 6 und 12 Sekunden. Die CPU-Auslastung ist sehr hoch, wenn osdteletext offen ist. osdteletext wird, wie das ganze OSD, per OpenGL gerendert. Man sieht bei intel_gpu_top eine Änderung der Auslastung im Bereich Render/3D, wenn man osdteletext öffnet. Daher sollte das nicht träge sein.

- Im WebIf stürzt der VDR in einer Endlosschleife ab, wenn man auf VDR OSD geht.

- Plymouth stürzt mit backtrace beim Starten und Herunterfahren ab. Wo findet man diesen backtrace in den Logs? Live funktioniert Plymouth, installiert aber nicht mehr.

- ACPI SDHCI eMMC wird nicht erkannt. PCI SDHCI eMMC schon. War bei MLD 5.4 auch schonmal Thema, wurde dort gelöst und funktioniert.
https://www.minidvblinux.de/forum/index.php/topic,8180.msg66510.html#msg66510

- Einmal eingerichtetes WLAN lässt sich nicht mehr entfernen. Es wird getrennt, verbindet nach Neustart aber immer wieder.

- Atom x5 z8350 analog Audio wird nicht erkannt, bzw. lässt sich im WebIf nicht auswählen.

-

Support Log id ist: IeMdMs

Ich werde hier weitere Auffälligkeiten ergänzen und gelöste Probleme streichen. Ich hoffe, dass diese Vorgehensweise okay ist. Falls es bessere Wege gibt, so teilt mir diese bitte mit.

Mit freundlichen Grüßen
Marcus

EDIT: Scrollproblem genauer beschrieben.
EDIT: Scrollproblem offensichtlich zwei verschiedene Probleme -> gesplittet.

[clausmuus]

Das Scrollproblem klingt danach, dass für das Anzeigen des OSD nicht die GPU verwendet wird. Wobei ich nicht weiß, ob es da Unterschiede gibt, je nachdem was für ne Grafikkarte man verwendet, oder ob sich da irgendwas in den Einstellungen des Ausgabe Plugin konfigurieren lässt. Ich selbe verwende immer seitenweises Scrollen, weshalb ich nicht mitbekommen würde, wenn das auch bei mir auftreten würde. Das muss ich also erst mal bei meinen Testsystemen beobachten.

Die Hohe Systemlast ist nicht normal. Ist da ein Prozess sichtbar, der CPU Last Produziert, oder ist lediglich der Load hoch? Load heißt ja nicht zwangsweise CPU. Die Load kann auch durch andere Komponenten wie Netzwerk oder Festplatte produziert werden. Da würde schon ein USB Stick reichen der ne Macke hat, und auf Anfragen nur verzögert antwortet (hatte ich gerade erst bei einer Server SSD).

[Marcus]

Es wird definitiv die GPU für das OSD verwendet.
1. Im OSD unter Softhddevice steht es
2. intel_gpu_top zeigt es mir an. Unter Render/3D steigt die Auslastung, sobald ich das OSD öffne oder noch weiter, wenn ich scrolle.

Die hohe Systemlast wird ausschließlich vom VDR-Prozess erzeugt. Und indirekt wohl auch durch Netzwerk, denn ich nutze ja streamdev-client. VDR braucht lt. htop ca 25-30% CPU. Wenn ich VDR beende, ist die Load bei 0,01, welches dann noch von ssh und htop erzeugt wird. Die hohe Load am Anfang können wir ignorieren, ich habe mittlerweile herausgefunden, dass das der epgsync mit dem Server ist. Aber im laufenden Betrieb pendelt es zwischen 1,6 bis 2,0. Man sollte aber auch den Atom im Auge behalten, auf einem Core i9 wäre das vermutlich nichmal wahrnehmbar.

USB-Stick kann ich ausschließen. Es finden keine nennenswerten Schreib- oder Lesezugriffe auf den Stick statt. Die Load ist auch bei einem Live-Test so hoch, und da ist das FS im RAM.

Dieses ziemlich träge Verhalten kommt wohl nur durch das scrollen des OSD Inhalts zustande. Wobei ich nicht verstehe, warum das heutzutage noch ein Problem sein sollte. Der Atom ist zwar relativ schwach auf der Brust, aber das sollte die GPU beschleunigen. Ich hätte nämlich erwartet, dass ich eine Auslastung des Blitters (2. Zeile bei intel_gpu_top) beim Scrollen sehen würde. Der ist aber grundsätzlich 0%. Der ist eigentlich genau für sowas zuständig. Siehe dazu https://de.wikipedia.org/wiki/Bit_blit

[Marcus]

Hier mal ein paar Screenshots. Der VDR lief seit mindestens 30 Minuten einfach so vor sich hin. Habe die FB nicht angefasst. Es läuft phoenix HD via DVB-C (streamdev-client).

[clausmuus]

Mein N100 System hat in Ruhe ein Load von 2,5 bei einer VDR CPU Last von 12%
Das Scrollen geht flüssig und steigert die CPU Last um 2%.

[Marcus]

Der N100 ist sehr viel performanter als der alte z8350 von 2016. Daher fällt mir das so extrem auf. Geh mal ins Menü "System" - "VDR Setup" - "Sonstiges" und scroll da mal und beobachte dabei die CPU-Auslastung. Ich weiß nicht warum, aber dort ist es bei mir extrem. Auch ohne dass der gesamte Bilschirminhalt mit jeder Zeile verschoben wird. In allen anderen Menüs, Aufnahmen z.B. oder EPG, da scrollt es erst ganz normal. Erst wenn er anfängt den gesamten Inhalt zeilenweise zu verschieben, wird es lahm.

[neumann2k]

Welches Skin verwendest Du?

[Marcus]

Ah, richtig. Das ist sicherlich auch wichtig zu erwähnen. Aber leider nix wildes. Ich nutze den Standard LCARS Skin. Von dem würde ich jetzt mal die geringsten Probleme erwarten.

[clausmuus]

Ich habe jetzt auch noch den RPI 4 getestet. Auch bei dem geht alles flüssig. Der Load ist durchgängig bei 3 und CPU < 10%

[Marcus]

Ja ist schon seltsam. Mich wundern zwei Dinge. Erstens, warum ist es in den VDR Einstellungen "Sonstiges" generell so langsam? Was ist in diesem Menü besonders? Weil dort wird ja nur der Cursor (der breite Balken) nach unten verschoben. Und zweitens, wenn der gesamte OSD Inhalt gescrollt werden muss, warum wird dazu nicht der Blitter benutzt? Dafür ist er da. Dass es dann auf lowest end Hardware klemmt, ist klar. Wie gesagt, N100, Core ix, oder was auch immer hat da wohl weniger Probleme mit. Aber diese Frage gehört wohl nach upstream. Entweder an den Entwickler von softhddevice, oder sogar noch weiter an die Jungs von OpenGL.

[Marcus]

Ich habe gerade nochmal mit der MLD 5.4 verglichen:

Das Scrollverhalten im VDR Einstellungsmenü "Sonstiges" ist interessanterweise dort genau so schlecht. Das scheint also eine Eigenart von diesem speziellen Menü im VDR selbst zu sein. Warum auch immer.

Aber! In Menüs in denen der OSD-Inhalt gescrollt werden muss, also z.B. Aufnahmen und EPG, scrollt die 5.4 deutlich besser/flüssiger. Das fällt praktisch nicht auf. Leider gibt es für die 5.4 kein intel_gpu_top. Daher kann ich nicht nachsehen, ob hier der Blitter dazu verwendet wird, oder ob das aus anderen Gründen besser funktioniert.