Beiträge von HarryH

Bei den Kabeln ist die Chance die richtigen zu erwischen größer wenn man auf die Zertifizierungslabel achtet. Dahinter steckt wohl mehr der rechtliche Zwang die Spezifikation einzuhalten, als bei Angabe der Versionsnummern ala HDMI 2.x o.ä.

• "High Speed HDMI Cable with Ethernet": >= HDMI 1.4 >10.2Gbps
• "Premium High Speed HDMI Cable with Ethernet": HDMI 2.0 / 4K@60Hz 18Gbps
• "Ultra High Speed HDMI cable": HDMI 2.1 48Gbps
• "Ultra96 HDMI cable": HDMI 2.2 96 Gbps
  
  Quellen: https://www.hdmi.org/resource/cables, https://hifi.de/ratgeber/hdmi-2-1-28673

Hi Schokii,

Du hast einen RPi5 mit der neueren Hardware Revision 2712D0 bekommen. Dafür braucht es Patches in der Mesa Bibliothek. Nimm ein aktuelles LE12 Nightly build, da sind diese schon enthalten und Du kannst später auf 12.0.2 wechseln sobald diese released wird.

Wird gern übersehen: die aktuellen Images stehen ganz unten.

https://test.libreelec.tv/12.0/RPi/RPi5/

Das HAT wird anscheinend aktuell gar nicht automatisch erkannt, zumindest sehe ich 0 Hinweise darauf in Deinem Log. Füge bitte mal diese Zeile am Ende Deiner config.txt ein:

dtoverlay=rpi-tv

und starte den RPi neu.

Wenn Du Dich per SSH mit LibreELEC verbunden hast, erhältst Du nach der Anmeldung als Nutzer: root / Passwort: libreelec (wie chach schon erwähnte) eine Eingabeaufforderung. Dort gibst Du einfach den Aufruf dmesg | grep cxd ein und drückst die ENTER/RETURN-Taste. Danach solltest Du ein paar Ausgaben wie diese erhalten:

[ 5.644582] cxd2880: cxd2880_attach: CXD2880 driver version: Ver 1.4.1 - 1.0.5
[ 5.644591] cxd2880 spi0.0: DVB: registering adapter 0 frontend 0 (Sony CXD2880)...
[ 5.645195] cxd2880_spi: cxd2880_spi_probe: Sony CXD2880 has successfully attached.
[ 7.590045] cxd2880 spi0.0: DVB: adapter 0 frontend 0 frequency 0 out of range (174000000..862000000)
[ 24.940126] cxd2880: cxd2880_set_frontend: sys:16 freq:474000000 bw:8
[ 25.968053] cxd2880: cxd2880_set_frontend: tune result 0

Die entsprechenden Ausgaben können bei Dir abweichen und gegebenenfalls Fehlermeldungen beinhalten. Gar keine Ausgabe wäre ebenso ein Hinweis darauf, dass der Treiber gar nicht geladen wurde.

Zur Erläuterung:

dmesg ruft die Kernel Meldungen seit dem letzten Boot ab. Durch das Pipesymbol | wird diese deutlich umfangreichere Meldungsflut an den Befehl grep weitergeleitet. Hinter dem grep steht die Zeichenkette "cxd" nach der mit grep gefiltert/gesucht wird. Großkleinschreibung wird bei diesem Aufruf beachtet, so dass er auf die Zeilen mit "cxd2880 ..." anspringt und nur diese Zeilen ausgibt. Mit dmesg ohne das gepipte grep dahinter kannst Du das gesamte Kernel Log abrufen.

Ich glaube Du unterliegst da einem Denkfehler.

Das Aktivieren von "Debug-Logging" via GUI erhöht die "Gesprächigkeit" im kodi.log. Das war schon richtig. In diesem Log stehen aber nicht die Meldungen des Kernels drin, welche Du mit dmesg | grep cxd gefiltert abfragen könntest.

Wenn Du Dich an die im vorigen Beitrag verlinkte Beschreibung von LibreELEC hältst, wird bei "Paste system logs" nicht nur das kodi.log auf einen temporären Logstorage hochgeladen und Du erhältst einen Link unter dem diese Logs aneinandergereiht aufgerufen werden können. Den Link kannst Du hier dann posten.

Solltest Du Bedenken haben dabei zu viele Informationen preiszugeben, ist der Weg über SSH mit dmesg | grep cxd nicht ganz so hilfreich wie ein vollständiges Debug-Log - liefert aber erste wichtige Informationen.

In die richtige Richtung gedacht, aber da es sich hier nicht um das bei der Fehlersuche hilfreiche Debug-Protokoll von LibreELEC handelt sondern ausschließlich KODI, sind da das notwendige Kernel Log und auch die config.txt nicht enthalten.

Hi ihr 2,

chach
LibreELEC hat einen angepassten OS-Unterbau, der nicht auf einer Standard-Distribution wie Raspbian o.ä. basiert. Der meiste Teil steckt in einem read-only Squashfs Image. Paketmanager wie apt stehen daher nicht zur Verfügung. Es ist damit auszukommen was an binaries vorhanden ist, manches lässt sich via Addon nachinstallieren. Für die reine Prüfung ob die Hardwarekombination überhaupt mitspielt, könnte der Wechsel auf eine SD Karte mit Raspbian/PiOS zielführend sein - da gebe ich Dir recht.

Raspi5Fan
Bei einem HAT wird normalerweise beim Booten die ID aus dessen EEPROM ausgelesen und das Overlay (enthält die Treiberaufrufe/Einstellungen) mitgeteilt, welches nachgeladen werden muss. Hier kann es unter Umständen schon mal zu Fehlern kommen, vor allem gab es mit dem RPi5 Mitte des Jahres noch grundlegende Schwierigkeiten. Ein aktueller Kernel + Bootloader/Firmware im RPi5 sind da Pflicht. Dafür kann es notwendig sein, dass Du ein aktuelles LE 12 Nightly Build verwendest, denn LE 12.0.0 und 12.0.1 sind schon etwas "gereift".

Unabhängig davon ob Du PiOS oder LibreELEC verwendest, sollte der Treiber für den Tuner im Log auftauchen. Schau mal was da so gemeldet wird, eventuell liefert das schon ein paar Hinweise:
dmesg | grep cxd

EDIT: Als SSH-Client für Windows bietet sich PuTTY an. Gibt es einzeln oder auch im WinSCP-Paket enthalten. Windows 10/11 haben inzwischen auch eigene Spielarten an Bord bzw. lassen sich nachinstallieren wie OpenSSH-Client. Ist reine Geschmackssache...

Zitat von schumi_64

Hallo Harry,

das ist schon alles fertig gewesen. Dank einem ADDON Namens GPIO Monitor, von SlyGuy war das sehr einfach.

Hätte mich eigentlich wundern müssen, wenn es fehlt. Aber diese Info war vorher an mir vorbeigegangen ....

Na, wenn sich das samt Display so schick zum Abspielen für Musiksammlungen anbietet. Hast Du schon darüber nachgedacht die Tasten ebenso zu nutzen und an die GPIOs zu verdrahten?

Es gibt eine fiese Regression im Linux Kernel das CIFS-Modul betreffend:
[REGRESSION] Corruption on cifs / smb write on ARM, kernels 6.3-6.9 - James Young

Ich vermute Du hast ein aktuelles LE im Einsatz und damit einen 6.6er Kernel oder ggf. eine andere betroffene Kernel Version > 6.2.16 und < 6.10.9. Das dort beschriebene Phänomen ist nicht auf die ARM-Plattform (RPi) beschränkt, sondern nur zufällig die Testplattform. Auf meinem Desktop-System konnte ich ein ähnlich gelagertes Verhalten nachstellen, bevor ich den Eintrag aus dieser Mail-Liste gefunden habe. Keine Angst, gibt noch mehr davon. https://lore.kernel.org/linux-cifs/9bc…p.fastmail.com/
Bei mir sorgte dieser Bug für ca. 1 halbes Jahr lang für korrupte Downloads mehrerer ca. 2GiB Firmware-ZIPs (Offline-Update) für unseren Fernseher beim direkten Speichern auf das NAS via SMB-Mount. Lokales Speichern und nachträgliches Kopieren mit cp oder mv hat den Fehler nie nachvollziehbar getriggert. Diese Downloads (Rechner- und Browser-unabhängig) allerdings schon. Der gleiche Download via Windows durchgeführt war wiederholbar fehlerfrei. Testdownloads mit anderen großen Dateien wie ISOs waren nicht geeignet um es regelmäßig zu provozieren.

Also bevor sich Meldungen häufen: "Habe es gerade probiert, bei mir geht es ohne Probleme." Reicht nicht als Testcase.

Wen es interessiert was in den Dateien verändert war: Die korrupten Stellen in den ZIP-Files waren an unterschiedlichen Stellen immer durch 0x00 Bereiche ersetzt. Bei jedem Downloadversuch an anderen Stellen. Für einen TS-Stream ist sowas natürlich Gift.

In meinem Fall mit 6.5 und 6.8 Kernel hatte ich mir einen Workaround erarbeitet. Den Cache für das Mount abschalten. Das kannst Du ja mal probieren und in Deinen Mount-Optionen unterbringen "cache=none". Wenn Du diesen Mountpoint nur zum Herausschreiben der Aufnahmen verwendest, sollte der Performanceverlust nicht ganz so ins Gewicht fallen. Beim Auflisten von großen Verzeichnisstrukturen mit vielen Ordner/Dateien ist es allerdings spürbar.

Auf meinem Desktop bin ich auf Kernel 6.11. gewechselt, seitdem komme ich wieder ohne diesen Workaround aus. Daher meine Annahme, es handelt sich um die selben Bugs die James Young und Zack Weinberg dort ausführlich beschreiben.

NFS ist auch nicht zwingend fehlerfrei, könnte aber dieses SMB-Problem umschiffen. Ob eine schnelle SD-Karte mit genügend Kapazität für mindestens 2 Aufnahmen auf einem RPi3 für eine Gegenprobe ohne File-Share schnell genug angebunden ist, kann ich gerade nicht einschätzen ...

TS ist nicht gleich TS. Diesen Teil (er)kennen viele Nutzer nicht und melden dann "Mein Player XY spielt die Aufnahme nicht ab", " Die Aufnahme ruckeln..." o.ä. Auch "Meine Aufnahmen sind kaputt..." habe ich da schon gelesen.
An der Stelle setzt TS-Doctor als erstes an und bringt es in einen konformen TS-Datenstrom. Welche Sonderlocken die Receiver beim Aufnehmen durch manipulierte Zeitstempel, Metadaten u.ä. verursachen kann ich jetzt nicht im Detail fundiert wiedergeben.
Für SD-Aufnahmen konnte man früher Cuttermaran mit entsprechendem Toolset aus ProjectX und tsmuxer verwenden um Aufnahmen framegenau zu schneiden. Bei dem Prozess fielen automatisch auch defekte TS-Aufnahmen auf und die Metadaten wurden korrigiert. HD Datenströme kodiert als H.264/H.265 sind für solche framegenauen Manöver nicht geeignet und man muss den gesamten Datenstrom re-encoden. Daher wurde Cuttermaran da wohl auch nie mehr weiterentwickelt.
Dennoch versucht der Autor von TS-Doctor die Eingriffe so wenig invasiv wie möglich zu gestalten. Dazu gehört auch die Korrektur von Metadaten die das Abspielen verhindern, Ausgleich von Zeitversatz und Korrektur von defekten Blöcken. Manches sind anscheinend "Lunker" im Audiostream durch die Sender selbst verursacht. Wenn es ein oder mehrere kostenlose Tools gibt, welche dies adäquat genauso können, spricht doch nichts dagegen dabei zu bleiben.
Die Frage war "Wie kann ich am einfachsten ..." - nicht "Wie kann ich für Lau ..."

Bei Eurer Grundsatzdiskussion über TS-Aufnahmen, dürft ihr den Empfangsweg nicht außer Acht lassen. TS-Datenströme in sich sollten normalerweise fehlerfrei und genauso fehlerfrei auf dem Aufnahmegerät abspielbar sein. Beim Transfer zum und späterem Abspielen am PC o.ä. spielen die restlichen Gimmicks wie Zeitstempel und Metadaten meist eine Rolle. Netzwerk kommt aus meiner Erfahrung erst zum tragen, wenn die Aufnahme direkt aufs File Share (NFS/SMB) erfolgt.
Sollte SAT als Empfangsart in Verwendung sein, ist das viel häufiger auftretende Problem, dass ein 2. Tuner der an der selben SAT-Verkabelung (gleicher LNB/Switch) angeschlossen ist beim Zu/Wegschalten "Pixelgewitter" verursacht. Ursache ist die schlechte Entkopplung der verschiedenen Ausgänge am Quad-LNB oder MultiSwitch untereinander. An diesen Stellen sind die TS-Datenströmen unweigerlich korrupt und Tvheadend würde entsprechend nur "Datenmüll" auf die Platte schreiben.

Ist kommerziell, aber TS-Doctor könnte da der komfortabelste Weg dafür sein. Lässt sich 30 Tage in Ruhe ausprobieren...

Wenn es für die ersten Tests nur an den Abhängigkeiten hakt, kannst Du die Installation der "Raspberry Pi Tools" manuell ausführen: LibreELEC Repo -> Programm-Addons

Hi BulliM ,
Deinem ursprünglichen Ansatz folgend, das Bild des RPi2 ordentlich auf dem TV-Schirm wiederzugeben:
video=HDMI-A-1:1280x720M@60 oder video=HDMI-A-1:1280x720M@50 in der cmdline.txt (nicht in die config.txt !) in der Bootzeile hinter "quiet" mit einem Leerzeichen getrennt anhängen hattest Du auch schon probiert, oder?

Hintergrund: Dein Fernseher kann lt. Deinem Kommentar nur HD ready, und 1366x768 wird z.B. vom RPi4 nicht mehr unterstützt da keine ganzzahlige Teilung durch 8. https://www.raspberrypi.com/documentation/…-raspberry-pi-4
Mit einer höheren Auflösung als 720p zuzuspielen macht wenig Sinn, wenn das verbaute Panel sowieso nicht mehr hergibt. Eventuell sparst Du Dir damit die Overscan/Underscan Korrektur via RPi und kannst das Bild passend per TV justieren.

Hi BulliM,

ich selbst hab mit den Overscan Settings noch nie herumgespielt (eher nach dem Service Menu für den Fernseher gesucht um das Problem an der Wurzel anzugehen )
Eventuell ist Dir Beitrag 3 eine Hilfe: https://raspberrypi.stackexchange.com/questions/1425…king-on-raspi-4

Hallo PvD,

dann sollte ich der Fairness wegen den Text lieber ändern in:

Zitat

Riecht eher danach, dass das Event-Handling mit diesem Skin an irgendeiner Stelle fehlerhaft umgesetzt wird oder an KODI fehlerhafte/unerwartete Werte erhält.

Ich habe immer noch das Gefühl, es gibt bei dieser Formulierung ein Schlupfloch mich ggf. falsch zu verstehen. Weder das Skin noch Du sollte(st) als Zielscheibe herhalten...

Die Info, dass es auf den anderen Plattformen bisher nicht nachstellbar ist, ist ein wichtiger Hinweis. Ich habe nur die Befürchtung, dass es deutlich länger dauern könnte die konkrete Ursache zu lokalisieren. Wenn ein Betroffener die Interna des Skins kennen/verstehen würde (wie Du), könnte er mit diesem Wissen sich durch Deaktivieren verschiedener Features dem Auslöser des Problems nähern und hätte "mehr in der Hand" um auf die Entwickler zuzugehen.

Naja, ganz so einfach wird die Erklärung nicht sein, sonst hätte der Versuch mit Swap zum Erfolg geführt. Riecht eher danach, dass das Event-Handling im Skin an irgendeiner Stelle fehlerhaft umgesetzt ist oder an KODI fehlerhafte/unerwartete Werte übergibt.

Was Du mal probieren könntest, den GPU-Speicher anzuheben. In der config.txt von gpu_mem=76 auf 96 oder 128 ändern. Danach Reboot um die Änderung zu übernehmen.

Da Du eine "gewachsene" Installation/Konfiguration benutzt, haben sich genügend Baustellen aufgetan zum Kontrollieren und ggf. Beheben. Ich hätte deshalb schon mal eine ToDo Liste:

- IPTV Add-ons deaktivieren, das müllt das Log ungemein voll - vor allem wenn Du es sowieso nicht benutzt.
- Skin auf default Estuary stellen - wichtig: kein Mod benutzen -> gibt gerade eine Diskussion im LibreELEC Forum mit ähnlichen Problemen die Du beschreibst nach 11.0.3

Wenn die beiden genannten Dinge nicht schon eine Besserung bringen:
- spiele mal etwas mit den Einstellungen unter Player -> Videos -> Wiedergabe u. Verarbeitung
-> Bildwiederholrate anpassen: an / aus
-> Wiedergabe mit Bildschirm synchronisieren: an / aus
-> PRIME Render Method: Direct-To-Plane
-> DRM-PRIME - Hardware-Deinterlacing ausschalten
- Bootloader aktualisieren (war zumindest bei Deinem Debug Log von dem 11er LE noch auf Stand 2020)

Hi,

dachte schon Du drückst Dich um das Update. Hätte ich aber auch verstanden, wenn Du vorerst bei LE 11 geblieben wärst, weil Du auf bestimmte Plugins angewiesen bist oder ähnliches.

Durch die Umstellung von 32bit auf 64bit müssen auch die entsprechenden Addons auf 64bit aktualisiert werden. Dies passiert zwar im Hintergrund weitestgehend automatisch, dauert aber manchmal und könnte eventuell der Grund für Deine Beobachtung mit IPTV sein.

Widewine muss man wohl am besten händisch leeren und neu installieren, falls man darauf angewiesen ist. Unabhängig davon ist die aktuelle Version davon gerade noch etwas buggy. Aber das Problem scheint bekannt und wird sicherlich bald gelöst.

Der Vollständigkeit halber: Die Firmware Partition hättest Du per /flash erreichen können ohne die SD-Karte ausbauen zu müssen. Zum Bearbeiten muss man die Partition mit rw remounten um sie auch beschreiben zu können. So wie es auch für das Ändern der config.txt beschrieben ist:
https://wiki.libreelec.tv/configuration/config_txt

Tipp: mmcblk0p1 -> mmcblk0 = Gerät (SD) -> p1 = Nummer der Partition

@DaVu ,

bei dem Link zum Log fehlt nur die Endung .log Ich hatte den Verdacht die Forensoftware mit dem automatischen Ersetzen hat wieder zugeschlagen.

msfox ,

nein, warten lohnt nicht. Du kannst auch versuchen Bei Deiner vorhanden Installation wie im verlinkten Thread beschrieben, die 2 Firmwaredateien händisch zu ersetzen. Sie sind anscheinend kompatibel mit LE11. Hätten andere nicht das gleiche Problem, hätte es den dortigen Thread nicht gegeben. Nur haben nicht alle solche exotischen Videodateien mit unvollständigen Informationen im Datenstrom. Außerdem gibt es genügend Nutzer, die solche Probleme nicht an der Quelle melden wo die Entwickler erreichbar sind.

Wenn Du nicht auf LE12 wechseln willst, bleibt noch der Weg LE10 frisch aufzusetzen und hoffen die Addons sind noch alle verfügbar oder mit dem Problem leben.