MLD-6.x > General

MLD 6.5 Bugs/Probleme, die mir beim Testen bisher aufgefallen sind

(1/10) > >>

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 langen Menüs, in denen der gesamte OSD-Inhalt verschoben werden muss, ist sehr langsam und die CPU geht gegen 100% auf einem Kern. MLD 5.4 läuft hier etwas besser. Während bei dem 5.4 die CPU fast komplett ausgelastet ist, ist das Scrollverhalten nur minimal, fast nicht merklich, langsamer. Das scheint ein Grenzfall zu sein, bei der 5.4 geht es gerade noch so, bei der 6.5 nicht mehr. Lösungsmöglichkeit: Den z8350 etwas tunen. Die CPU darf im Wyse 3040 nur 2 Watt verbrauchen. Wenn die GPU das Video dekodieren muss, bleibt für die CPU kaum noch Leistung übrig. Diese taktet dann nur mit dem Grundtaktfrequenz von 480 MHz, was wohl nicht ausreichend ist. Man kann per MSR Interface das Leistungslimit aufbohren, der SoC wird dabei etwas wärmer. Der 3040 hat aber einen ziemlich großen Kühlkörper, daher bleiben die Temperaturen im grünen Bereich. Erledigt! Das war kein Bug in der MLD, sondern ein zu geringes Powerlimit im UEFI von DELL. Claus hat den Intel PowerCap Treiber im Kernel hinzugefügt. Jetzt kann man das Powerlimit überschreiben. Die CPU taktet nun bis auf die vollen 1920 MHz, statt wie bisher nur 480 MHz.

- Scrollverhalten in den VDR-Einstellungen "Sonstiges" ist sehr langsam und die CPU geht gegen 100% auf einem Kern. Ist es in MLD 5.4 x86 aber auch. In MLD 5.4 auf Raspberry Pi 2 läuft es flüssig. Das tritt nur mit aktiviertem SVDRP peering auf. Lösungsmöglichkeit siehe oben, Powerlimit anheben.

- 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 läuft auf MLD 5.4 flüssig und verbraucht kaum CPU-Zeit, die Uhrzeit springt im Sekundentakt weiter. 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. Das funktioniert mit angehobenem Powerlimit nun zwar deutlich besser, aber nicht gut. Hier ist definitiv ein großer Unterschied zur MLD 5.4. In der MLD 5.4 braucht osdteletext nur sehr wenig CPU, fast nichts, in der 6.5 aber extrem viel.

- 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, wenn keine Tastatur angeschlossen ist. Gelöst!

- 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.

- Im EPG werden die VDR-Fonts bzw. WarEagle-Icons (der "runningman" oder die Uhr) nicht angezeigt, stattdessen * und t/T. In den VDR-Einstellungen unter OSD gab es früher an 4. Stelle den Punkt "WarEagle icons: ja/nein". Das fehlt bei der 6.5 in den Einstellungen. Das Paket vdr-font-symbols, von dem ich glaube, dass es die Symbole enthält, ist installiert. Im EPG von EPGsearch werden sie wohl auch benutzt, zumindest die Uhr für programmierte Timer. Nur im VDR-eigenen EPG nicht.

-

Support Log id ist: IeMdMs

Ich werde hier weitere Auffälligkeiten ergänzen/updaten 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.
EDIT: Erkenntnisse zum Scrollproblem ergänzt und fehlenden VDR-Font hinzugefügt.
EDIT: Weitere Infos zu den fehlenden VDR-fonts hinzugefügt.
EDIT: Plymouth stürzt nur ab, wenn keine Tastatur angeschlossen ist.
EDIT: Powerlimit angehoben, Scrollverhalten gelöst!
EDIT: Plymouth ist gelöst!

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%.

Navigation

[0] Message Index

[#] Next page