Beiträge von HarryH

  • Welches Gehäuse für RPi 5

    Das Add-on oder alternativ das verlinkte Script von Argon40 wird für die Lüftersteuerung und die Unterstützung der verschiedenen Einschaltknopfoptionen "geordneter Shutdown, Reboot .. " benötigt. Zusätzlich installiert das Add-on noch die Konfigurationsdateien für die Argon IR Remote. Einfluss auf die Audioausgabe hat das keine.

    LE12 kann zickig sein wenn der TV und/oder AVR unvollständige/falsche EDID-Informationen liefert. Bei dem Konstrukt sollte auch ein nach "Premium High Speed HDMI Cable with Ethernet" oder "Ultra High Speed HDMI Cable" zertifiziertes Kabel verwendet werden um die 4K Auflösungen fehlerfrei zu unterstützen. Die Gehäuse von Argon40 sind etwas verschrien bei den LibreELEC-Entwicklern/Moderatoren, da die Fertigungsqualität stark schwankt.

    Stelle bitte als erstes sicher den HDMI-0/HDMI-A-1 Port (am nächsten zum Stromanschluss positioniert) zu benutzen, nur dieser unterstützt z.B. auch CEC. Je nach Fernseher, kann es dann noch notwendig sein die HDMI-Konfiguration des TV anzupassen oder einen anderen HDMI-Port zu probieren.

    Im Worst Case hilft nur den RPi5 ohne Gehäuse testen um dieses als Fehlerquelle auszuschließen.

    PS: Mit einem Link zum Debug Log sieht man mehr.

  • CEC geht nicht mehr trotz Aktivierung beim Booten

    Zitat von Raspi5Fan

    Deswegen schrieb ich ja oben, NUR DER LINKE HDMI-Anschluss funzt problemlos. Oder es ist eben ein Prob. mit dem Kabel.

    Das mag bei Dir und bei mir so sein. Bei Jan Tenner nicht, weshalb er hier als auch im LE Forum nach Hilfe dazu sucht. Die möglichen technischen Ursachen, und warum die pauschale Aussage "benutze den linken (HDMI0)" Port vom LE Softwarestand abhängig ist, wurden hier auch schon erwähnt... Wenn Du die Troubleshooting-Runde nochmal von vorn drehen willst, ist das ja okay - nur ändert "schreien" nichts am Wahrheitsgehalt. ;)

  • CEC geht nicht mehr trotz Aktivierung beim Booten

    Grundsätzlich wäre ich bei der selben Schlussfolgerung wie Du.

    Es gab aber auch schon den Fall, dass es dennoch das Kabel war o. in Kombination mit dem verwendeten HDMI Port am TV einhergeht. Ebenso haben manche Kunststoffgehäuse für den RPi das saubere Zusammenfügen Stecker/Buchse mechanisch blockiert, war nicht viel - hat aber gereicht.
    Wenn Du noch ein anderes Kabel haben solltest, versuche es ruhig mal zu tauschen und ggf. an einem anderen HDMI Port des Fernsehers. Die HDMI-Signale sind sehr hochfrequent, da braucht es nicht viel um Ärger zu verursachen. Auch andere hochfrequente Signalquellen wie USB3.x o. WLAN in direkter Nähe sind als Verusacher möglich, gerade bei mangelhaften Kabeln.

    Sorry, war ein Tippfehler t -> d drin. Mit getedid create kann man von einem TV/Projektor usw. die EDID Daten mit den unterstützen Auflösungen/Tonformaten usw. als Dateiabbild abspeichern. Diese liest der RPi beim Booten wieder ein und verwendet sie statt der eigentlich vom TV/AVR gerade gemeldeten EDID Informationen. Kann man z.B. als Workaround gebrauchen wenn der RPi oft vor dem TV und/oder AVR hochgefahren wird, damit er dennoch ein Bild liefert.
    Wenn man das nutzt darf man nicht vergessen bei einer Veränderung z.B. neuer TV, anderer HDMI Port o.ä. das alte Abbild mit getedid delete wieder zu löschen.
    https://wiki.libreelec.tv/configuration/edid

  • CEC geht nicht mehr trotz Aktivierung beim Booten

    So wie Du das Verhalten beschreibst, benutzt Du HDMI1 statt HDMI0. Offiziell wird CEC nur an HDMI0 unterstützt. Das war zwischendurch anders, weil der Versuch gestartet wurde beide Ports gleichzeitg zu unterstützen. Das hatte mehr Probleme verursacht, als das es hilfreich war und wurde nach 12.0.1 wieder entfernt.

    Wenn es bei HDMI0 keine höheren Auflösungen anbietet, deutet es auf ein Hardwareproblem hin: Kabel, Lötstellen o.ä.

    Oder hast Du in der Vergangenheit mit getedid create herumexperimentiert? Auch ein Gehäuse mit internen HDMI Adaptern war des öfteren ursächlich.

  • "Richtig Gute" HDMI Kabel

    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.ä.

  • Raspberry Pi DVB-T / DVB-T2 TV Hat ist wech...

    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:

    Code
    [ 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.

  • Raspberry Pi DVB-T / DVB-T2 TV Hat ist wech...

    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.

  • Raspberry Pi DVB-T / DVB-T2 TV Hat ist wech...

    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...

  • Kaputte Aufnahme heilen

    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 ...

  • Kaputte Aufnahme heilen

    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.

  • Overscan / Underscan

    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.