Recent Posts

31
Danke für die Hilfe mit evtest. Der Sundtek-Remote Kanal bleibt stumm.
Ich habe jetzt nen alten IR-Empfänger aus meiner Resterampe ausgelötet und für den Raspi konfektioniert, hängt nun am GPIO18. Was soll ich sagen...:
- Funzt perfekt!
- Danke für das super ergonomische Programm+WebIF zum Identifizieren und Anlernen der FB !!
- Dabei hat sich dann auch quasi nebenbei ergeben, dass meine FB das NEC-Protokoll verwendet. Der Sundtek hätte also was empfangen müssen, tut er aber nicht.
- (Wenn man NEC wählt ist es, wie ich vermute, auch 38kHz. Das hab ich nicht überprüft, denn der IR-Empfänger ist hübsch in ein Blech-Hütchen verpackt, also Typencode verdeckt..., d.h. keine Ahnung ob der nur auf 38kHz lauscht oder "Breitband" kann. Ich unterstelle einfach, dass "NEC" immer auch "38kHz" heißt.)
Ich beende diesen Topic jetzt für's erste, aber ohne "erledigt" Marker. Falls irgend Jemand das Sundtek-Remote Dings mal zum Fliegen bringt künnte er hier netterweise schreiben, wie er das dann geschafft hat. Wer es am Laufen hat könnte evtl. auch mal mit "tools" checken, ob die Sundtek FB wirklich NEC blitzt. Ach ja und dann sollten wir uns alle dahigehend einig sein, dass es hier um die Sundtek SkyTV Dual Ultimate geht, die Sundtek ja generell ohne FB verkauft - anders als den "Single" SkyTV-Stick. Sundtek "behauptet" aber, dass auch die "Dual" eine FB auswerten kann, und es ist ja auch ein IR-Empfänger zwischen den beiden SAT-Buchsen verbaut.
32
@Franky und @cllausmuus
Super toll dass ihr euch um mein Problem kümmert, herzlichen Dank. Wie im vorigen post zu lesen war das WLAN-Problem lediglich mein eigener Dummy-Idiotenfehler. Bei der ersten Installation hat das WLAN ja problemlos funktioniert, nachdem die MLD mal installiert war und die Hardware-Descriptors aktualisiert hatte.
Die Sache mit der EmergencyShell passiert aber unabhängig davon ob ich das WLAN korrekt eingerichtet habe.
@Franky: Ich hatte natürlich zu allererst ein RaspiOS aufgesetzt und die aktuellsten Firmware-Images geholt. Ich nehme an dass die MLD das nicht kann. Original war was vom November 2025 im EEPROM, es gab was von 2026 (ich glaube es war 23.Januar 2026, kann aber auch noch was neuer sein - wenn gewünscht sehe ich nochmal genau nach). Vielleicht hattest du zusätzlich zum Bootproblem auch mit dem WLAN Probleme weil deine Firmware noch etwas älter ist?
@clausmuus: Während meiner Kontakte zu Sundtek haben die mir gesagt, dass es mit dem "neuesten" Treiberpaket irgend ein Problem gegeben hätte und ihr in der MLD deswegen bewusst nicht den neuesten Treiber verwendet. Welche Versionen bzw. Build-Datumswerte da genau gemeint waren habe ich allerdings nicht erfragt. Deshalb bitte Vorsicht mit der Aktualisierung der Sundtek-Software - nicht dass du wegen mir einen neuen Build baust der dann bei zig Anderen nicht mehr geht.
Abgesehen davon: Ich möchte hier gaaanz herzlich danke sagen, dafür dass ihr so engagiert für mich arbeitet. Bin beeindruckt!
33
@clausmuus: Wir geraten etwas off-topic mit der WebIF-Geschichte, aber dies kann abgehakt werden, denn ich hab meinen Dummy-Fehler gefunden:
Ich fahre das WLAN mit einer festen IP-Adresse. Bei der ersten Installation hatte ich die auch richtig angegeben, aber beim zweiten Install war ich irgend wie "gereizt!!!" und hab die Subnetmaske verschlafen, d.h. nur "192.168.1.42" eingegeben und nicht "192.168.1.42/24". Maaaaan!!
Ich bitte hiermit untertänigst um Entschuldigung.
Dieser Fehler hatte dann zur Folge, dass erst mit Verbindung des LAN überhaupt ein Subnet bekannt gewesen ist und dann ging halt "alles" und ohne LAN ging "nichts".
Btw ich spreche das WebIF immer über eine IP an, nie über den Namen, deshalb weiß ich immer über welches IF ich die MLD gerade erreiche...
34
Hi Franky,

Danke mal wieder für Deine super Analyse!

Ich hatte vor einiger Zeit gelesen, dass Sundtek Ihre Treiber geändert hat, damit diese ohne ein LD_CONFIG auskommen, bzw. ohne Preload ihrer Libs. Dies habe ich bisher jedoch nicht übernommen (wenn ich mich richtig erinnere), da wir bisher keine Probleme mit dem Preload hatten.
Da es nicht gerade unwahrscheinlich ist, dass die beschriebenen Probleme damit zusammen hängen, werde ich mir das die nächsten Tage mal anschauen und umbauen.
35
Ich habe heute wieder meinen Test RPI5 reaktiviert und versucht das Problem mit der USB3-SSD und dem WLan zu reproduzieren.
Konfiguriert hatte ich die neu installierte MLD 6.5 (auf 32GB SD-Karte) erst mal für den SatIP Empfang per VTuner.
Dann nacheinander 2 unterschiedliche USB3-SSDs (256GB Intenso und 512GB PNY) als /data eingebunden.
Auf der Intenso war eine alte MLD 5.5 Installation vorhanden deren Data-Partition (XFS) ich als /data eingebunden habe.
Die 512 GB PNY habe ich beim Einbinden über die CheckBox "Datenträger löschen" neu Partitionieren und Formatieren lassen.
Mit beiden SSDs gab es dann erst mal keine Probleme.
Ich habe dann noch von Lan auf WLan um gestellt.
Da war dann zwar der Empfang per VTuner über die WLan Verbinung nicht mehr optimal (manchmal Ruckler), beim Booten gab es aber noch keine Probleme mit der USB-SSD.

Da GustavGans ja einen Sundtek Tuner an seinem RPI5 betreibt, habe ich auch mal das Sundtek Paket installiert und einen SundtekTuner reaktiviert.
Sobald die Sundtek Treiber aktiv sind, gibt es Probleme mit der USB-SSD und dem WLan beim booten.
Ich lande dann auch auf der EmergenyShell.
Mit Enter und exit wird dann zwar der Bootvorgang abgeschlossen und ich habe ein TV-Bild über den Sundtek-Tuner es funktioniert dann aber kein WLan mehr.
Das WebIF erreiche ich dann auch nur noch über die IP-Adresse des Lan-Ports.

Es muss nicht mal ein Sundtek Tuner an einem der USB-Ports angeschlossen sein.
Sobald die Sundtek-Treiber aktiv sind gibt es Probleme mit dem WLan-Chip des RPI5 und der als /data gemounteten USB3-SSD.

Sobald der Sundtek-Treiber wieder deinstalliert ist, bootet der RPI5 wieder ohne Probleme aber der Sundtek-Tuner funktioniert dann natürlich nicht mehr.
Wenn ich alternativ als /data wieder die System-SD einbinde bootet das System ohne Probleme auch bei installiertem Sundtek Treiber.
36
Hi,
Dein Problem mit dem Datenlaufwerk werden wir versuchen nachzustellen. Da ich selber keinen RPI-5 habe, werde ich's mit 'nem RPI-4 prüfen. Ansonsten muss einer unser Tester ran ;)

Was Dein WLAN Problem betrifft, dürfte die Erklärung recht einfach sein: Das WLAN hat eine andere IP als das LAN. Sofern Du versuchst den RPI über die LAN IP anzusprechen, wirst Du den natürlich nicht erreichen können, ohne angestecktes LAN Kabel. Und wenn Du's über den Namen versuchst, verweist der sicher auf die LAN IP, da diese zuerst da war, und sofern in der Fritzbox (oder ähnliches) bereits geändert, trotzdem noch 'ne weile in den Caches steht. Versuch's am besten mal über die WLAN IP, das sollte funktionieren.

Wieso Diene System SSD der ersten Installation voll war, kann ich nicht sagen. die vier Snapshots dürften nicht der Grund sein, da die MLD ja nur einige hundert MB belegt, und die Snapshots kleiner sind. Eventuell hattest Du auf der System SSD Aufnahmen gespeichert, bevor Du das Datenlaufwerk hinzugefügt hast. Die alten Aufnahmen werden dabei nicht gelöscht, sondern nur verdeckt.
37
Ich habe jetzt alles mit Standardwerten gemacht, EmergencyShell kommt beim Boot zuverlässig weiterhin. SupportLog: McjQ5B (oder yBrfiS).

Kurze Geschichte:
Keine Ahnung wo die menu.xml hin ist... ich konnte auch nirgends eine Standard-Vorlage finden. Aber klar: Das ist der Grund dafür, dass das OSD nicht mehr geht. Hätte ich selber drauf kommen müssen...
Geschaut, ob Neuformatieren (aus den MLD-Einstellungen, also XFS) gegen die Bootprobleme hilft, tut es NICHT.
Nach dem Neu-Formatieren sind natürlich die VDR-Ordner weg, neu angelegt.
Mir fiel auf (WebIF/Information), dass die BTRFS Partition seit einigen Tagen randvoll ist, es lagen nur 4 Snapshots drauf, die ich mal bis auf den letzten gelöscht hatte. Freier Speicher 1,7MB von 14,xGB??
Hab dann den letzten Snapshot zurückgespielt, hätte ja sein können dass das die menu.xml wiederherstellt. Nach der Reboot-Anforderung ging nichts mehr (gar nichts!).
RPi bzw. MLD konnte nur noch durch "Stromausfall" zum Neustart bewegt werden und landete dann in der EmergencyShell, aus der er nicht wieder zu retten ist.
Systemdisk (eine nagelneue 16GB SDCard) in anderem Rechner geprüft: Das BTRFS ist beschädigt und kann nicht repariert werden. Also:
NEUINSTALLATION, diesmal alles auf Standard:
- LAN verwendet, denn WLAN geht mit dem RPi5-Image ja nicht.
- Installation per WebIF über LAN (schön performant).
- SSD gleich verbunden und nochmal komplette Disk gelöscht.
- Nur VDR angewählt, keine anderen Funktionen, auch keinen Server, das Dings läuft ja direkt am TV.

Klar, ich musste alle Einstellungen nochmal machen. Kein Backup, kein Mitleid. Aus einem Backup, das ich JETZT habe, hätte ich mir auch menu.xml, Kanalliste etc. holen können, na ja - verbucht unter dummy-user cleverness.

WLAN wieder eingerichtet.

Aktueller Status:

Bootproblem ist unverändert da: Wenn ich mal einen Neustart brauche, dann lande ich garantiert nach laaangem Timeout in der EmergencyShell und mit <Strg>+D geht's dann weiter = Live-TV nach wenigen Sekunden. Ich glaube an ein grundsätzliches Problem beim MLD Boot, das ich nicht selber lösen kann. Bitte um Hilfe...
Vielleicht sollte doch die aktuelle Hardwareunterstützung ins Install-Image integriert werden? Vielleicht sollte ich das selber machen, habe aber noch nicht verstanden wie das Pimpen des Image geht.

NEUES Problem: Ich erreiche das WebIF NUR DANN über WLAN, wenn auch das LAN-Kabel steckt! Wenn ich statt WebIF übers Netz das lokale WebIF nutze (kann ich aus dem VDR-Systemmenü aufrufen), sagt es mir, dass es sehr wohl mit dem WLAN verbunden sei (Einstellungen/Netzwerk/... sowie Information), Trotzdem geht nicht mal ein PING zum Gateway (network unreachable). Sobald das LAN-Kabel steckt erreiche ich das WebIF über LAN und auch über WLAN. (IPs sind natürlich so konfiguriert, dass sie sich nicht beißen...) Das war bei meiner ersten Installation nicht so. Vermute dass es da eine Priorität gibt, die ich umdrehen müsste. Wo kann ich das tun?
38
Gegenüber der MLD-5 hat sich beim Softhddevice die Voreinstellung für den Deinterlacer geändert. Daher mein Hinweis mal zu prüfen ob der passend eingestellt ist. Es wird ja auch eine andere Variante des softhddevice verwendet.

Der Overscan, den viele TVs per Voreinstellung aktivieren, und auch die Grafikkarte aktiviert sorgt auch für eine miserable Bild Qualität.

Das Problem beim Ton unter Kodi ist, das Kodi als Flatpack läuft, und es nicht gerade trivial ist, den die Soundkarte dort hin durchzureichen. Das hatte ich vor nem Jahr mal geschafft, aber dann gab's nen flatpack update, und nun passt wieder nicht mehr.

Ich hatte vor einigen Wochen mal mit Pipewire rumgespielt, da ich ein paar Anforderungen hatte, die anders nicht zu lösen waren. Das ganze ist aber nicht trivial und erst recht nicht einfach so einzurichten, dass es bei allen Usern ootb funktioniert. Da es obendrein für den MLD Einsatz für den normalen User keine Vorteile bringt, werden wir dies auf Absehbare Zeit nicht zum Standard machen. Pipewire zieht halt zwischen Soundkarte und App eine weitere Abstraktionsschicht ein, die dann auch noch konfiguriert werden muss, passend zur Hardware.
Trotzdem habe ich die Voreinstellungen der Pipwire Pakete eingecheckt und die stehen als Pakete zur Verfügung. Nur durch die individuellen Einstellungen musst Du Dich dann selber quälen :) Wenn Du damit herum spielst, musst Du beachten, dass wir kein PulseAudio an Bord haben, aber viele Anleitungen setzen genau dies voraus und verweisen auf PulseAudio Tools um Pipewire zu konfigurieren. Erforderlich ist es aber nicht.

Ich verwende Pipewire, weil mein N100 Mainbord seit einigen Monaten dazu neigt, sich sehr lange Zeit zu lassen, bis die Soundkarte sichtbar wird. Wenn zu dem Zeitpunkt der VDR bereits gestartet ist, gab's kein Ton. Die Pipewire Abstraktion erlaubt es, dem VDR eine Virtuelle Soundkarte vorzusetzen, und die Physikalische einzubinden sobald diese auftaucht.
Obendrein will ich gleichzeitig zu der 5.1 Soundausgabe, den Ton im 2.0 Format an einen Bluetooth Kopfhörer senden. Auch das ist mit purem Alsa nicht möglich. Ich scheitere aber bisher da dran, Pipewire davon zu überzeugen die Kopfhörer mit Stereo anzusprechen, und nicht Mono.
39
Ok, -v {video} {disable}. Ich konnte keine Doku dazu finden, daher die Frage.

Da ich seit 2010 Nvidia-GPUs für VDR einsetze kenne ich natürlich die Deinterlacer-Einstellungen usw. auf dem FF. Irgendetwas muß bei MLD jetzt aber schief laufen. Wie gesagt hatte die alte MLD-Version keine Probleme diesbezüglich und EasyVDR 3.5, das ich immer noch von einer anderen Platte booten kann, auch nicht. Bei meinen Freund exisitiert ja wie gesagt dasselbe Problem, obwohl der einer andere GPU hat (ich GT220, er GT1030).

Was das Ganze jetzt mit Overscan zu tun haben soll ist mir schleiferhaft, Overscan ist jedenfalls nicht aktiv.

Da EasyVDR jetzt erstmal länger verwendet wird muß ich mal schauen, wann ich wieder MLD booten kann, dann schaue ich mir mal /etc/vdr/conf.d/50_... an, vielleicht ist dort ja ein Hinweis auf das Qualitätsproblem zu finden.

OT: Gibt es irgendwo eine Doku über das Konstrukt, wie MLD die Tonausgabe steuert? Ist geplant, das momentane Konstrukt durch Pipewire zu ersetzen bzw. mit Pipewire neu aufzubauen?
40
Die beiden Argumente werden beim VDR-Start durch passende ersetzt. Welche gewählt wurden, kannst DU in der Datei /etc/vdr/conf.d/50_... nachschauen.
{video} steht dabei für den vedeo-Modus und {disable} wir ddurch -d ersetzt, wenn das Plugin im detached Modus starten soll.

In den Plugin Einstellungen im VDR OSD kannst Du den Deinterlacer auswählen, der verwendet werden soll. Per Voreinstellung ist einer gewählt, der auf jeder Hardware funktioniert, dafür aber nicht sehr leistungsfähig ist.
Sollte es doch nicht am Deinterlacer liegen, kommt auch ein automatischer Overscan in Frage. dies würde dafür sorgen, dass das TV Bild hoch skaliert wird. Erkennen lässt sich das z.B. da dran, dass der Mauszeiger an allen vier Seiten ausserhalb des sichtbaren Bereiches verschwindet, oder dass ein OSD dass 100% des Bildschirm füllen soll, an den Rändern abgeschnitten wird.