Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - franky

1
Hallo Uwe,

beim RP2040 Zero gibt es keine Konfigurationsdatei für die Tastenbelegung im System, wie es bei anderen FB Empfänger der Fall ist.
Beim RP2040 wird die angelernte Tastenbelegung immer direkt auf dem RP2040 gespeichert.
Auch wenn du mal eine Tastenbelegung über das WebIF änderst wird zuerst die vorhandenen Tastenbelegung vom RP2040 eingelesen und nach einer Änderung wird diese beim Speichern wieder direkt auf dem RP2040 abgespeichert.
Bei einer neu installierten MLD 6.5 funktioniert also ein bereits angelernter RP2040 ootB mit der FB, mit der er vorher angelernt wurde.

2
Hallo Marcus,

ich habe mir mal die Logs mit und ohne Tastatur angeschaut.
So richtig erschließt sich mir das Problem nicht.
Anscheinend wird aber der BootScreen von Plymouth über die FrameBufferConsole (fbcon) ausgegeben.
Bei der fbcon scheint es dann ein Problem zu geben, wenn keinen HW-Tastatur erkannt wurde.
Dann wird anscheinend versucht noch eine Virtuelle Konsole zu laden was dann aber bei Plymouth zum Abbruch führt.
Als Anlage mal die Auszüge aus dem Log.
Bei Bedarf auch die kompletten Logs.

Evtl. kann ja Claus etwas damit anfangen.

3
Hallo Marcus,

ich kann das mit der Tastatur bestätigen, habe es aber bisher nie bemerkt, da ich generell neben einer FB auch eine Tastatur verwende.

Bei meinem ersten Test ohne Tastatur auf dem N3000 (nur mit dem CIR) hatte ich schon den Verdacht, dass es an dieser alten CherryTrail GPU-Generation liegt.
Dieser Verdacht hat sich aber nicht bestätigt. Es sind alle Intel GPU-Generationen betroffen.
Ich habe bisher auf 6 weiteren Systemen unterschiedlicher Intel-Generationen nur mit FB aber ohne Tastatur getestet.
Da habe ich dann immer anstatt dem Plymouth Kringel bis zum Start des XServers Konsole Ausgaben am TV.
Beim Herunterfahren ebenfalls kein Plymouth Kringel sondern stattdessen Konsole.

Meine IR-Empfänger auf RP240 Basis verhalten sich hier, im Gegensatz zu deinem Flirc, wie eine echtes Tastatur HID-Device.
Ich habe daher statt der RP2040 andre USB-Empfänger (X10-RF, MCE-USB, Streamzap ..) verwendet.

Gruß
Klaus

4
Bis zur Version „mld-image-netinstall-x86-64 (250518).iso“ wurde der Ton immer im Modus „auto“ auf dem TV automatisch ausgegeben.
Gerhard,
das würde ja meine Vermutung bestätigen, dass die Ursache beim alsa-init Paket vom 19.05.25 liegt.
Im Image vom 18.05.25 war noch die Vorgänger-Version von alsa-init enthalten, bei der auch für den Ton-Ausgang auto eine asound.conf erzeugt wurde.
Mit der aktuellen Version vom 19.05.25 wird aber bei auto definitiv keine asound.conf mehr erzeugt.
Daher dann auch kein Ton.

Ich vermute mal, das kann Claus relativ schnell beheben. ;)

5
@claus ich habe das mit dem fehlenden Ton auch gerade an Testsystemen festgestellt, die schon ein paar Tage nicht aktualisiert worden sind.
Ich vermute es liegt am aktuellen alsa-init Paket vom 19. Mai.
Nachdem dieses bei meinem Testsystem bei dem der Ton auf auto stand, aktualisiert war, hatte ich nach einem Neustart keinen Ton mehr.
Ich habe das jetzt auch noch auf anderen Systemen mit eingestellter Ton-Quelle und neuem alsa-init Paket getestet.
Sobald ich die Ton-Einstellung lösche und somit den Ausgang wieder auf auto umstelle, habe ich nach einem Reboot keinen Ton mehr.
Ich habe mich dann mal unter /etc umgeschaut. Mit der Einstellung auto wird keine asound.conf erzeugt.
Wenn ich einen Ton-Ausgang auswähle wird wieder eine asound.conf erzeugt.
Wenn ich diese Einstellung lösche und somit auf auto umstelle, wird die asound.conf gelöscht und keine neue erzeugt.

Das mit der Benennung des aktiven HDMI-Tonausgangs nach der Marke des erkannten TV ist schon länger so.
Ist mir in Zusammenhang mit der HbbTV Mediatheken-Funktion und der Tonausgabe bei Chromium schon aufgefallen.
Ich finde das sehr sinnvoll, da man gleich den aktiven Ausgang erkennt.

6
OK, dann scheint das limitierende bei Dir die CPU zu sein.
Mich wundert aber, dass der überlastete CPU-Kern nicht hoch taktet, denn eigentlich sollte deine CPU bis 1920 MHz hoch gehen können.
In deinem Screenshot bleibt sie aber bei 479MHz und ist mit 100% am Anschlag.

Ich hab's mir mal bei meinem N3000 angeschaut und dieses mal nur mit 64 MB shared Mem im Bios.
Da taktet ein CPU-Kern von den beiden auf über 2GHz hoch und hat dabei eine Auslastung von 61,2%.
Die GPU taktet auf 440MHz hoch bei einer Render-Last von knapp 80%.
Daher auch durchgängig flüssiges Scrollen.

7
Also bei meinem N3000 wie auch bei vielen anderen älteren Intel-Systemen wird der shared Memory abhängig von RAM fix über das BIOS zugewiesen.
Beim N3000 war shared Memory auf Auto konfiguriert und im Hauptmenü wird da bei 4GB RAM ein zugewiesener shared Memory von 256 MB angezeigt.
Ich kann dann aber in den erweiterten Einstellungen den shared Memory  auf 64, 128, 256 und 512 MB konfigurieren.
Da werde ich auch mal die 64 und 128 MB testen.

Laut intel-gpu-top wird die GPU des N3000 wie deine als Intel Cherryview (Gen8) GPU erkannt.
Meine GPU taktet abhängig von der Render Last zwischen 120 und 320MHz.
Bei meinen bisherigen Tests habe ich auch festgestellt, dass die GPU-Last besonders mit offenem OSD stark von der Auflösung und Wiederholfrequenz abhängt.
Die höchste habe ich FullHD 60Hz, wobei die Render-Last mit LCARS beim schnellen Scrollen bis auf 85% bei 320MHz GPU-Takt hochschnellt.
Wäre jetzt interessant wie hoch deine GPU maximal takten kann.
Die Render-Grundlast ohne offenem OSD liegt bei FullHD zwischen 20 und 25% bei ca. 150MHz GPU-Takt.
Bei aufwendigen Skins wie Skin-Designer geht die Last beim Scrollen im OSD bis auf 100% hoch und ich habe auch solche Effekte, von denen du berichtest.

Mit 50Hz ist die Render-Last dann etwas geringer.
Deutlich weniger Last (ca. die Hälfte) verursacht HD (1280x720) mit 50Hz.

Welche Auflösung und Wiederholfrequenz hast du im WebIF konfiguriert?
Falls du FullHD verwendest, versuche mal stattdessen HD.
Der Wyse3040 hat ja keinen HDMI-Port sondern DP-Ports.
Gehst du direkt mit DP auf einen Monitor mit DP-Port oder verwendest du einen aktiven DP-HDMI Adapter zum Monitor bzw. TV?


8
Hallo Marcus,

ich habe versucht das Problem mal auf meinen alten, schon immer kritischen, mobilen Airmont-Systemen der Braswell Generation nachzustellen.
Außer meinen ehemaligen VDR-Server mit N3150 habe ich mein schwächstes Braswell-System, eine Asrock BeeBox N3000 mit 4GB RAM (256MB shared für iGPU), ausgemottet.
Dein Atom x5 z8350 gehört ja als Tablet-CPU auch zu den CPUs mit Airmont Architektur, wobei die iGPU des N3000 nur minimal mehr Grafik Power hat.

Das von dir beschriebene Problem, besonders beim VDR Einstellungsmenü "Sonstiges", kann ich jedoch auch beim N3000 nicht feststellen.
Da läuft das Scrollen in allen OSD-Menüs sowohl mit Tastatur als auch FB über den internen CIR flüssig.

Flirc habe ich nicht getestet, da ich den wegen seinem ruckeligen Verhalten schon lange nicht mehr verwende.

Das scheint eher eine Eigenart dieser Airmont Tablet Atom CPU/iGPUs der CherryTrail-Generation zu sein.
Bin schon am überlegen, ob ich mir so einen Wyse 3040 antun soll, um dein Problem nachzustellen.

9
Hallo Marcus,

die intel-gpu-tools gibt es schon in der MLD6.5, muss aber erst installiert werden.
Es ist im Paket igt-gpu-tools enthalten.
Nach der Installation kann man es mit intel_gpu_top starten.
Also beim Start nicht - sondern _. ;D
Roland hat auch noch ein anderes Tool nvtop integriert, das man auch für Intel iGPUs verwenden kann.

Gruß
Klaus

10
Der Receiver zwischen VDR und TV könnte natürlich auch solche Ton-Probleme verursachen.
Wenn die Ton-Probleme wieder auftreten wäre ein Test mit direkter Verbindung zum TV sinnvoll.

Etwas seltsam an deinen Debug-Logs ist wieder das sehr verkürzte massages Log bei dem wieder nicht der komplette VDR Start mit allen Meldungen von softhddevice zu sehen ist.

Welchen Log-Level hast du eigentlich im WebIF eingestellt?


11
Ich hatte das Problem bisher bei meinen Intel-Systemen (gleiche Generation wie deines) noch nicht.
Weder mit der MLD 5.5 noch mit der MLD 6.5.

Wie Claus, kann ich in deinem Log keinen eindeutigen Hinweis auf den Tonausfall finden.
Das Log ist aber auch nicht komplett.
Man sieht nicht wie der VDR und seine Plugins komplett geladen werden.
Es fehlt auch die komplette Start-Meldung von softhddevice.

Welchen Ton-Ausgang verwendest Du eigentlich, HDMI oder Analog bzw. SPDIF?
Lade dir noch mal über das WebIF einen kompletten Satz DebugLogs herunter und poste diese Archiv-Datei.

12
Allgemein [ General ] / MLD 6 Bitte um dvb-tbs für TBS6902
« on: April 29, 2025, 13:00:39 »
Das tbs Paket lässt sich bei mir auch problemlos aus dem nightbuild installieren.

root@MLDServer1:~# apt install tbs
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  tbs
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 3.843 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 https://mld6.minidvblinux.de/nightbuild/deb/genericx86_64 ./ tbs 1.0-r0.0 [3.843 kB]
Fetched 3.843 kB in 1s (4.983 kB/s)
Create a snapshot of '/mnt/root/@root' in '/mnt/root/2025-04-29 12:59'
Vormals nicht ausgewähltes Paket tbs wird gewählt.
(Lese Datenbank ... 17788 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../tbs_1.0-r0.0_amd64.deb ...
Entpacken von tbs (1.0-r0.0) ...
tbs (1.0-r0.0) wird eingerichtet ...

13
Allgemein [ General ] / MLD 6 Bitte um dvb-tbs für TBS6902
« on: April 29, 2025, 12:57:08 »
Bei meinen Systemen wird das TBS Paket auch im Nightbuild Repo gefunden.
Genauer gesagt, ist es im /nightbuild/deb/genericx86_64 Repo zu finden.

root@MLDServer1:~# apt update
Ign:1 https://mld6.minidvblinux.de/nightbuild/deb/all ./ InRelease
Ign:2 https://mld6.minidvblinux.de/nightbuild/deb/core2-64 ./ InRelease
Ign:3 https://mld6.minidvblinux.de/nightbuild/deb/genericx86_64 ./ InRelease
Hit:4 https://mld6.minidvblinux.de/nightbuild/deb/all ./ Release
Hit:5 https://mld6.minidvblinux.de/nightbuild/deb/core2-64 ./ Release
Hit:6 https://mld6.minidvblinux.de/nightbuild/deb/genericx86_64 ./ Release
Hit:7 https://mld6.minidvblinux.de/nightbuild/deb/core2-64_extra ./ Release
Ign:8 https://mld6.minidvblinux.de/nightbuild/deb/all ./ Release.gpg
Ign:9 https://mld6.minidvblinux.de/nightbuild/deb/core2-64 ./ Release.gpg
Ign:10 https://mld6.minidvblinux.de/nightbuild/deb/genericx86_64 ./ Release.gpg
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
root@MLDServer1:~# apt list tbs
Listing... Done
tbs/unknown 1.0-r0.0 amd64

14
Allgemein [ General ] / MLD 6 Bitte um dvb-tbs für TBS6902
« on: April 29, 2025, 10:04:30 »
Hallo,
die TBS-Treiber sind nicht automatisch mit im Kernel sondern als extra Paket in der aktuellen MLD 6.5 enthalten.
Du kannst sie über das WebIF unter Pakete - SUCHE - tbs nachinstallieren.
Nach einem Reboot sollte die TBS-Karte dann erkannt werden.

15
Allgemein [ General ] / MLD 6.5 x86 Installation auf eMMC
« on: April 28, 2025, 14:35:53 »
Hallo Marcus,

stimmt die UHD600/605 der GeminiLake Generation funktioniert mit beiden Intel Treibern.
Im Wiki gibt es da eine schöne Seite, wo man sieht, welche Intel iGPUs von welchem Treiber unterstützt werden.
https://www.minidvblinux.de/wiki/mld/entwicklung/intel-gpu
Ich habe übrigens VAAPI fähige Intel Systeme ab der BayTrail (N2820, J1900), IvyBridge und Haswell Generation, mit denen ich die MLD seit der 5.4 teste.

Ich finde die Bildqualität des "alten" i965 VAAPI-Treibers deutlich besser, als die des neuen iHD Treibers.
Daher bevorzuge ich aktuell die Intel-Systeme der KabyLake, CofeeLake und GeminiLake Generation, die auch schon per VAAPI UHD dekodieren können und auch bei UHD mit dem alten Intel-Treiber ein deutlich besseres Bild haben, als mit dem iHD Treiber.

Dass die MLD 5.4 nur GPUs bis zur HD6xx der KabyLake Generation unterstützt, liegt übrigens daran, dass die Intel-Treiber in der 5.4 zu alt sind.
Die MLD 5.5 hat dann schon neuere Treiber (jedoch noch keinen iHD), die dann auch die UHD600/605 unterstützen.