[clausmuus]

Ich habe die Posts gefunden, die vermutlich diesen Fehler betreffen. Ab hier gibt's die Antwort von Sundtek: https://www.vdr-portal.de/forum/thread/137119-fehler-in-libmediaclient-so/?postID=1386928#post1386928
Demnach gab es Probleme mit dem Lesen von Dateien, wenn dies in Mehreren Thrads parallel erfolgt. Im aktuellen Sundtek Treiber sollte das behoben sein.

[clausmuus]

Es gibt ein Update für den RPI5. Ihr könnt mal testen, ob es hilft (und weiterhin funktioniert), wenn ihr das VDR und sundtek Paket aktualisiert.
Das sundtek Paket enthält auch ein Versions Update.
Ich habe das so geändert, dass das Preload der Lib nur noch bei ausgesuchten Prozessen erfolgt (z.B. beim VDR), und nicht mehr global für alles.

[franky]

@claus
Der neue Sundtek-Treiber hat bei meinem RPI5 leider keine wirkliche Verbesserung gebracht.
Läuft sogar schlechter, da jetzt leider die Tuner nicht mehr funktionieren.
Ich habe extra noch mal neu installiert, aber der VDR findet die Sundtek Tuner nicht mehr.
Jun 28 17:30:27 MLD vdr[2061]: [2061] no DVB device found
Jun 28 17:30:27 MLD vdr[2061]: [2061] ERROR (dvbdevice.c,1945): /dev/dvb/adapter1/frontend0: No such device or address
Jun 28 17:30:27 MLD vdr[2061]: [2061] ERROR (dvbdevice.c,1945): /dev/dvb/adapter0/frontend0: No such device or address
Der mediaclient läuft jedoch und erkennt auch den Dual-Tuner.

Und wenn ich eine USB3-SSD als /data einbinde auch wieder das Emergency-Shell beim Booten des RPI5.

Die einzige eher positiv Änderung betrifft den Plymouth Bootscreen.
Bisher hatte beim RPI4 und RPI5 der Plymouth Bootscreen nicht mehr funktioniert, sobald das sundtek Paket installiert war.
Da gab es anstatt dem pulsierenden MLDHD Logo nur einen grauen Bildschirm.
Jetzt wird beim RPI5 auch bei installiertem sundtek Paket wieder das pulsierende Logo angezeigt.

Ich habe den Sundtek Tuner heute auch mal bei einem x86er (NUC7P mit Pentium J5040) getestet und da gibt es die Probleme nicht.

[clausmuus]

Mir war ein Fehler beim sundtek Paket unterlaufen. Den habe ich korrigiert.
Bei meinem Test mit dem RPI-4 funktioniert die Änderung jetzt.

[franky]

@claus
Der aktualisierte Sundtek-Treiber funktioniert jetzt auch wieder bei meinem RPI5.
Leider gibt es aber immer noch das Problem beim Booten mit dem Mounten einer USB-SSD nach /data.
Ich habe auch anstatt einer USB-SSD verschiedene größere USB-Sticks getestet.
Der Bootvorgang mit dem jetzt pulsierenden MLD-Logo wird dann immer nach mehreren Minuten Wartezeit mit dem Emergency-Shell unterbrochen.

Sobald kein sundtek Paket installiert ist, wird die USB-SSD beim Booten ohne Probleme gemountet.
Ich habe mal das sundtek Paket wieder deinstalliert und anstatt des Sundtek-Tuners einen Terratec CinergyS2 USB-Tuner verwendet, dessen Treiber schon im Kernel enthalten sind.
Da läuft das Booten und Mounten der USB-SSD ohne Probleme.

Beim RPI4 funktioniert der Sundtek-Treiber deutlich besser und auch mit einer USB-SSD wird der Bootvorgang nicht mit dem Emergeny-Shell unterbrochen.
Der Bootvorgang dauert aber trotzdem deutlich länger, als ohne Sundtek-Treiber.
Im Log sieht man dann auch beim RPI4, dass bei installiertem Sundtek-Treiber das Mounten der USB-SSD erst nach mehreren Versuchen funktioniert.

Den neuen Sundtek-Treiber gibt es jetzt ja auch für das x86er Nightbuild.
Ich habe daher den Sundtek-Dual und neuen Treiber noch einmal mit dem NUC7P getestet.
Die MLD 6.5 auf einer internen SSD installiert und die externe PNY USB-SSD als /data gemountet.
Da gibt es überhaupt keine Probleme mit dem Sundtek-Treiber.

[rfehr]

@claus
Der aktualisierte Sundtek-Treiber funktioniert jetzt auch wieder bei meinem RPI5.
Leider gibt es aber immer noch das Problem beim Booten mit dem Mounten einer USB-SSD nach /data.
Ich habe auch anstatt einer USB-SSD verschiedene größere USB-Sticks getestet.
Der Bootvorgang mit dem jetzt pulsierenden MLD-Logo wird dann immer nach mehreren Minuten Wartezeit mit dem Emergency-Shell unterbrochen.

Sobald kein sundtek Paket installiert ist, wird die USB-SSD beim Booten ohne Probleme gemountet.
Ich habe mal das sundtek Paket wieder deinstalliert und anstatt des Sundtek-Tuners einen Terratec CinergyS2 USB-Tuner verwendet, dessen Treiber schon im Kernel enthalten sind.
Da läuft das Booten und Mounten der USB-SSD ohne Probleme.

Beim RPI4 funktioniert der Sundtek-Treiber deutlich besser und auch mit einer USB-SSD wird der Bootvorgang nicht mit dem Emergeny-Shell unterbrochen.
Der Bootvorgang dauert aber trotzdem deutlich länger, als ohne Sundtek-Treiber.
Im Log sieht man dann auch beim RPI4, dass bei installiertem Sundtek-Treiber das Mounten der USB-SSD erst nach mehreren Versuchen funktioniert.

Den neuen Sundtek-Treiber gibt es jetzt ja auch für das x86er Nightbuild.
Ich habe daher den Sundtek-Dual und neuen Treiber noch einmal mit dem NUC7P getestet.
Die MLD 6.5 auf einer internen SSD installiert und die externe PNY USB-SSD als /data gemountet.
Da gibt es überhaupt keine Probleme mit dem Sundtek-Treiber.

Hast du beim RPI5 mal unterschiedliche USB anschlüsse getestet,
für SSD und Sundtek.

Gruß,
  Roland

[franky]

Hi Roland,

das habe ich natürlich.
Ich habe alle möglichen Kombinationen getestet.
Interessant ist ja auch, dass überhaupt kein Sundtek Tuner an einem USB-Port angesteckt sein muss.
Es reicht, dass der Sundtek Treiber (also das sundtek Paket) installiert ist.
Sobald dann eine USB-SSD als /data eingebunden wurde, kommt es zu dem Problem, dass der Bootvorgang nach einigen Minuten im Emergency-Shell endet.
Da ist es dann auch nicht relevant an welchem USB-Port die externe SSD (oder USB-Stick) angeschlossen ist.

Gruß Klaus

[gustavgans]

Sorry ich trau mich jetzt noch nicht, selber zu testen. Die wunderbarste Frau auf Erden reißt mir den Kopf ab wenn ich ihr Baby ständig re-boote und dafür jedesmal seeeehr lange brauche.
Möchte aber paar Anmerkungen loswerden:
a) Bootproblem MLD-Logo
Ist bei mir genau so wie bei Franky. Nach dem Einschalten pulst das MLD-Logo, es dauert 3..5 Minuten bis ich in der EmergencyShell lande, mit <Strg>+D komm ich da raus und beim nächsten Versuch kommt nicht das pulsende Logo, sondern "drei Punkte" auf grauem Bildschirm, die nicht pulsen. Wieder Warten, wieder EmergencyShell. Nur manchmal "hilft" <Strg>+D und der VDR startet nach wenigen Sekunden mit laufendem Sundtek-Receiver und verbundener USB-SSD. Auch ich habe "alle" Varianten ausprobiert, welcher USB-Port für welches Gerät dient.
b) Raspi ist nicht gleich Raspi
Weil halt das Boot-Image im EEPROM und die Hardware/DeviceTree Daten der Distribution ihre eigene Rolle spielen, denke ich.
c) Raspi EEPROM Imagepflege
User: cs-7  on: December 01, 2024, 13:37:55  Topic: PI5, MLD 6.5, Paket Request rpi-eeprom-config hatte das Thema aufgemacht. Das Paket heißt "rpi-eeprom" und ja, die MLD kennt es. Ich liste mal kurz mein Ergebnis:

Code: [Select]

root@MLD:~# rpi-eeprom-update
BOOTLOADER: up to date
   CURRENT: Di 26. Mai 15:01:25 UTC 2026 (1779807685)
    LATEST: Mo 10. Mär 17:10:37 UTC 2025 (1741626637)
   RELEASE: default (/usr/lib/firmware/raspberrypi/bootloader-2712/default)
            Use raspi-config to change the release.Anmerkung: rpi-eeprom-update -h erklärt alles Weitere. rpi-eeprom enthält auch rpi-eeprom-config, wo man mit "--edit" die Bootreihenfolge ändern kann, wie im Topic von cs-7 beschrieben.
Aaaber: Dieses rpi-eeprom Paket ist nicht aktuell. Eventuell ist das github repository oder eben die Quelle, die MLD verwendet, etwas zu alt? Scheint auch so zu sein, dass DIESES rpi-eeprom Paket nicht nach  neuen Images schaut und nur das aus seiner eigenen Build-Time kennt - keine Ahnung. Ich wollte es hier aber g'schwind erwähnen.
Puh, das Grundproblem führt ja ganz schön tief in die Innereien. Die libc-Korrekturen, von denen im Sundtek Forum die Rede war, haben wir in der MLD?

[clausmuus]

@franky,
möglicherweise wird beim Update des sundtek Paketes der Eintrag in der /etc/ld.so.preload nicht gelöscht. Überprüfe das mal und entferne den gegebenenfalls.
Ich hatte bei meinem test ob das neue sundtek Paket funktioniert kein Update gemacht, sondern frisch installiert.

Die libc-Korrekturen sind nicht in der MLD enthalten. Ich bin aber auch nicht sicher, ob die relevant sind. Man könnte den Post auch so verstehen, dass Sundtek genau die Funktion überläd, die in der libc fehlerhaft sein soll. In jedem Fall sollte die Sundtek lib beim Booten nicht mehr geladen werden, sondern erst beim VDR Start. Sollte allerdings der VDR für die boot Verzögerungen verantwortlich sein, würde meine Änderung gar nicht helfen. In dem Fall müsste das Boot Problem allerdings verschwinden, wenn das VDR Paket entfernt wird
Ich werde morgen noch mal testen, ob ich das Problem mit meinem RPI-4 nachstellen kann und überprüfe dann die Details.

Übrigens sollte ein Drücken der ESC Taste beim Booten zwischen MLD Logo und Boot Meldungen umschalten. Da kann man dann auch sehen, wobei das Booten hängen bleibt.