Diese Meldung normal und verbose kommt vom MLD Bootloader und erscheint auch, wenn man auf einer angeschlossenen normalen USB Tastatur beim Bootvorgang eine Taste drückt. Dann wird der Bootvorgang mit dieser Meldung unterbrochen.
Es scheint also als ob der RP2040 von Helmut mit der alten Firmware vom Januar Tastendrücke empfängt obwohl er an der FB keine Taste gedrückt hat.
Mit der aktuellen Firmware war dann das Problem bei ihm verschwunden.
So habe ich auf jeden Fall das Problem von Helmut verstanden, konnte es aber bisher bei keinem meiner MBs nachstellen.
Posts by franky93128
-
-
Der Grund für Wakeup Probleme beim Powerknopf drücken liegt eventuell daran, dass das emulierte Eeprom am Ende des Flash liegt, und aufgrund der unterschiedlichen Größe bei One und Zero muss dann Wakeup (und eeprom map) neu angelernt werden. Wenn man die zugehörige Firmware nimmt, bleibt beim Firmware flashen das Eeprom ja erhalten. Aber eben nur, wenn es da liegt, wo die Firmware es erwartet.
Vielleicht habe ich die Beschreibung des Problems aber auch nicht richtig verstanden.Danke für deine Erläuterungen.
Ich glaube aber nicht, dass das der Grund für das Bootproblem bei Helmut war.
Er hatte einen neuen Zero noch ohne Firmware mit dem WebIF von MLD geflasht und dann die FB angelernt. -
jrie
Das mit der Erhöhung der Taktfrequenz im April von 130 auf 200 MHz ist sehr interessant.
Hinter der aktuell bei MLD 6.5 unter /lib/firmware bereitgestellten "irmp-rp2040-firmware.uf2" verbirgt sich tatsächlich "2025-01-29_23-41_waveshare_rp2040_one_hid_irmp_kbd"
D.h. mit der aktuell von MLD verwendeten Firmware vom 29.01.2025 arbeiten die RP2040 noch mit 130 MHz.Es würde also absolut Sinn machen, kurzfristig die Firmware auf den aktuellen Stand upzudaten.
Emma53
Helmut,
Könntest du mal bei deinem RP2040 Zero testen, ob das System mit der aktuellen One-Firmware beim Booten auch hängt?
Die erste Firmware-Version, bei der dein System keine Bootprobleme hatte, war ja die vom 21.05.2025, also auch schon nach der Erhöhung der Taktfrequenz. -
Danke für die schnelle Antwort.
Bei der MLD 6.5 wird beim Flashen der Firmware über das WebIF aktuell die Firmware-Variante des One für alle RP2040 HW-Varianten verwendet.
Mit der One FW-Variante liefen meine Zero's eigentlich ohne Probleme.
Nachdem ein anderer User jedoch bei seinem System beim Systemstart mit der One-Firmware auf seinem Zero Probleme hatte, habe ich auch mal auf meinen Zero's die aktuelle passende Zero-FW aufgespielt.
Damit laufen meine Zero's deutlich flüssiger beim Scrollen im OSD.
Es scheint mir also doch evtl. sinnvoll, die richtige FW-Variante zu verwenden.
Alle RP2340 HW-Varianten verwenden, so wie es ausschaut, die gleich Device-ID 1209:4445 und werden bei MLD 6.5 als "Raspberry Pi Pico" erkannt.
Sind daher anscheinend nicht über die Device-ID unterscheidbar.
Gibt es sonst eine Möglichkeit, die HW-Variante bei der Registrierung im System zu Unterscheiden? -
jrie
Hallo Jörg,in deinem git gibt es ja für die RP2040 Varianten Pico, One und Zero je eine Firmware Version.
IRMP_STM32_KBD/RP2xxx/build at master · j1rie/IRMP_STM32_KBD · GitHub
Worin liegen da die Unterschiede in den Firmware Varianten?
Ist es ratsam auf die jeweilige RP2040 Variante auch wirklich die entsprechende Firmware zu flashen?Ich habe festgestellt, dass prinzipiell jede RP2040 Firmware-Variante auf jeder RP2040 HW-Variante läuft.
Gruß
Klaus -
Und wenn ihr bei i6df137173e33937e13ca72c3350e5c304bc99fbf im Browser das java-script Debugging einschaltet, kommt der Fehler, dass LabelAndAction nicht definiert ist. Und wenn ihr dann den Browser Cache leert (manchmal muss man das auch 2 mal machen, in Firefox mit strg-F5), dann funktioniert es wieder. Korrekt?
Du hast Recht. Den Browser Cache hatte ich nicht geleert.
Nachdem der Browser Cache geleert ist, funktioniert auch wieder Pragramme und auch die Aufnahmen werden wieder angezeigt.
Diese Version funktioniert jetzt einwandfrei.
Man muss halt wissen, dass der Browser Cache am Besten mehrmals geleert werden muss.
-
Hier ein Screenshot mit der git Version der 3.5.2 von heute, bei der Programme nicht mehr funktioniert.
Mir ist mittlerweile auch aufgefallen, dass keine Aufnahmen mehr angezeigt werden.
Und hier der ein Screenshot der Version vor der Änderung, auf die ich dan der Snapshotfunktion von MLD zurück bin.
Da funktionierte der Menüpunkt Programme noch einwandfrei
-
MarkusE
Ich bin jetzt auch nochmal auf die live Version 3.5.2 von gestern vor der Änderung zurück.
Da funktioniert der Menüpunkt Programme noch einwandfrei.
Mittlerweile habe ich übrigens herausgefunden, weshalb die die Umlaute des ORF EPG bei MLD 6.5 nicht korrekt importiert wurden.
Es war das Paket glibc-gconvs nicht installiert. Nach dessen Installation werden auch bei ORF Kanälen die Umlaute korrekt dargestellt. -
Daher die Bitte an Euch, mit dem jetzt aktuellen git (commit -m "utf8-sanitize-multischedule") zu testen. Wenn damit der Fehler immer noch auftritt, könnt ihr mir ja hier Testdaten verfügbar machen.
Also bei mir funktioniert nach der Änderung die Zeitleiste der ORF Kanäle, auch wenn die Umlaute nicht korrekt importiert wurden.
Die Umlaute werden dann mit ? dargestellt.
Leider funktioniert jetzt der Menüpunkt Programme nicht mehr.
Bei Keinem Kanal werden mehr die Sendungen aufgelistet. Hier Kanal2 ZDF der gerade lief und EPG-Daten vorhanden waren.
-
Ich kann diesen Fehler hier mit ORF1 HD nicht reproduzieren.
Startet MLD den VDR mit "--chartab=ISO-8859-9"? Kannst Du einen einzelnen ORF Sender posten, bei dem der Fehler auftritt?
Bei MLD 6.5 tritt das bei allen ORF Kanälen, auch bei ORF1, auf.
Im VDR-OSD werden die Umlaute der EPG Daten nur als Rechteck angezeigt.
Ich nehme an, das ist auch das Problem von live 3.5.2.
Wir sind jetzt wieder auf live 3.5.0 zurück, das soweit funktioniert bis auf die Umlaute im ORF EPG, die als ? dargestellt werden.
Ja der VDR, aktuell Version 2.7.7, wird mit "--chartab=ISO-8859-9" gestartet.
Trotzdem wird anscheinend das EPG der ORF Kanäle nicht richtig importiert.
Welche VDR Version verwendest Du?
Werden bei dir die Umlaute korrekt dargestellt? -
Im git ist Version 3.5.2
Bei MLD 6.5 wurde live im Rahmen des Updates auf VDR 2.7.7 auf die Version 3.5.2 upgedatet.
Mit Version 3.5.2 habe ich und andere MLD-User ein Problem in Verbindung mit ORF Kanälen.
Sobald ich in der Zeitleiste von Live eine Kanal Gruppe auswähle, die einen ORF Kanal enthält, crasht live.
Unabhängig vom verwendeten Browser wird dann nur noch eine Seite mit "Error character conversion failed" angezeigt.
Im MLD-Log gibt es nur die Meldung "WARN tntnet.worker - http-Error: 500 character conversion failed"
Bei der Version 3.5.0, die vorher bei MLD 6.5 verwendet wurde, trat dieser Fehler nicht auf.
Kann den Fehler sonst noch jemand bestätigen oder hat eine Idee woran das liegen lönnte? -
Die Unterschiede in unseren softhddevice Einstellungen (SoftSync, BlackPicture, ...) machen für das Problem keinen Unterschied bei mir.
Mit Einstellungen wie SoftSync oder BlackPicture hatte ich auch schon verschiedene Varianten getestet, was ab das Problem nicht behoben hat.
Ich hatte daher wieder die Default Werte von MLD eingestellt. -
Ich glaube doch. Poste doch mal deine setup.conf.
Hier meine setup.conf.
Die softhddevice Einstellungen für 576i, also SD um das es hier geht, sind mit denen aus deiner geposteten shd.conf.txt identisch. -
Was passiert eigentlich wenn man softhdcuvid von jojo61 als Ausgabeplugin benutzt?
Vielleicht ist das da schon gefixt, und dann kann man das einfach übernehmen, statt zu suchen, was beim Decodieren schief geht.Im Prinzip eine gute Idee.
Mit MLD 6.5 kann ich es aber leider nicht testen, da softhdcuvid nicht in den Paketquellen verfügbar ist.
Bei MLD 6.5 gab es zwar in der Vergangenheit auch Versuche mit softhdcuvid, die aber immer gescheitert sind.
Da cuvid mit softhddevice von lnj einwandfrei funktioniert, wurde das Thema softhdcuvid bei MLD 6.5 nicht weiter verfolgt. -
neumann2k
Ich habe erst jetzt gesehen, dass dein System auf SD-Karte nicht mehr bootet.
Ich habe den Vorschlag von Roland mal getestet, um auf der SD-Karte auf eine älteren Snapshot zurückzugehen.
Einfach ohne SD-Karte mit dem NetInst Image von USB-Stick booten. Nach dem Booten von USB die SD-Karte einstecken.
Beim NetInst Image gibt es dann unter Snapshots noch ein Feld wo du den Datenträger mit den Snapshots wählen kannst.
Da kannst du dann die SD Karte und anschließend im nächsten Feld einen Snapshot auf der SD-Karte auswählen, auf den du zurückgehen kannst.
Danach sollte deine SD-Karte hoffentlich wieder booten.
-
Okay, also von USB booten klappt. Natürlich musste ich die SD Karte dazu entfernen. Wie kann ich jetzt in MLD die SD Karte ansprechen? Die wird nicht erkannt (weil wahrscheinlich nicht beim booten eingesteckt).
Ideen? Möchte sehr ungerne neu installieren, da dieser MLD auf LIRC läuft und ich daher einige Anpassungen vorgenommen hatte.
Du könntest mit deinem aktuellen System auf SD-Karte booten und dann deine konfigurierte MLD-Installation per Backup-Funktion im WebIF auf den USB-Stick schreiben.
Nach einem Shutdown die SD-Karte entfernen und mit dem Backup-System auf dem USB-Stick booten, mit dem du experimentieren kannst ohne bei deinem System auf SD-Karte was kaputt zu machen.
Das erspart dir dann auch eine Neuinstallation bei der du dann wieder alles neu konfigurieren musst. -
Seltsam ist ja, dass das Problem nur in Verbindung mit den Schnittmarken auftritt und nur bei SD-Aufnahmen der Pro7/Sat1 Sendergruppe.
Die Wiedergabe dieser Aufnahmen macht ja kein Problem.
Ich kann auch bei der Wiedergabe problemlos spulen und springen und auch wenn ich mit der Pause Taste pausiere läuft das Video wieder an.
Nur wenn ich durch Anspringen einer Schnittmarke (Taste 7 oder 9) pausiere, läuft das Video danach nicht mehr an und da gibt es dann diese "invalid frame" Meldungen. -
jrie
Ich habe jetzt neue Syslogs mit aktiviertem DEBUG in softhddevice erstellt.
Diesmal habe ich nur die Problematische Aufnahme gestartet, die erste Marke angesprungen und auf Play gedrückt.
Wenn der Fehler auftritt habe ich das Log erstellt.
Softhddevice ist jetzt deutlich gesprächiger.
Wenn das Problem auftritt fällt folgende Meldung auf, die sich laufend wiederholt:
vdr[874]: [mpeg2video @ 0x7f9da0000c00] Invalid frame dimensions 0x0.
vdr[874]: codec: video codec closeDieses Mal habe ich bei nVidia einen 2. Anlauf gebraucht. Beim ersten Versuch lief das Video einwandfrei an.
Habe aber nur beim auftretenden Problem ein Log erstellt. -
jrie
Ich habe gerade von Roland erfahren, dass DEBUG doch nicht beim Bau von softhddevice aktiviert war und er neu mit DEBUG bauen lässt.
Ich lade heute Abend nochmal neue Logs hoch. Dann hoffentlich mit ergiebigeren Meldungen. -
jrie
Ich habe anscheinend die Debug-Meldungen von softhddevice immer für reine Info-Meldungen gehalten.
Mit -l 2 sind diese Video- und Audio-Meldungen verschwunden und mit -l 3 wieder vorhanden.
Hier mal das Syslog des nVidia (GT1030) und Intel-Systems (J5040 mit UHD605) mit hoffentlich brauchbaren Debug-Meldungen.Nach dem Systemstart habe ich jeweils erst mal eine RTL-SD Aufnahme, bei der das Problem nicht auftritt gestartet und dort mit Anspringen der Schnittmarke 1 und 3 die Wiedergabe pausiert und wieder gestartet.
Danach dann das Gleiche mit der hochgeladenen Aufnahme wo das Problem auftritt.
Jedoch nach vergeblichen Start der Wiedergabe von Schnittmarke3 die Aufnahme bis zum Ende laufen lassen und danach remote das Syslog erstellt.
