Beiträge von HarryH

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.

Du kannst Dir das Image passend zu Deinem RPi herunterladen und in den .update Ordner ablegen. Danach den Neustart durchführen und etwas Geduld mitbringen für den Update-Prozess (KODI Logo).
Eine Neuinstallation ist natürlich risikofreier, da die sich nicht an einem veralteten Addon oder einer verwaisten Einstellung stören kann.

LibreELEC Raspberry - LibreELEC

Alternativ geht der Download auch direkt per SSH (Beispiel für RPi4)

cd /storage/.update
wget https://releases.libreelec.tv/LibreELEC-RPi4.aarch64-12.0.0.img.gz

EDIT:
Was das fehlende Angebot in der Liste der verfügbaren Updates betrifft… Es wird kein Update per GUI angeboten, da die bisherigen LibreELEC Images arm (32-bit) waren, und die neuen LibreELEC 12 Images für RPi4 u. RPi5 aarch64 (64-bit) Images sind.

Gibt es für Dich einen bestimmten Hinderungsgrund, dass Du nicht auf LibreELEC 12 gewechselt bist?

Ich weiß von einem Firmware-Bug, der den Player zum hängen bringt wenn im Video-Stream die Aspekt-Ratio Informationen plötzlich fehlen.

Betrifft genau diese Meldung aus Deinem Log:

2024-05-02 21:05:11.282 T:1321     info <general>: Skipped 153 duplicate messages..
2024-05-02 21:05:11.282 T:1321     info <general>: CVideoPlayerAudio::Process - stream stalled

Seit dem Wochenende ist auch die finale Version 12 erhältlich. Da steckt der Fix und tausend andere schon drin.

Außerdem ist mir aufgefallen: Dein Bootloader stammt noch aus 2020 und könnte auf Sicht auch Probleme verursachen.

Hi,

welche KODI Version setzt Du denn ein? Ich vermute Omega.
Ich kann jetzt nur für die LibreELEC-Umsetzungen primär für RPi sprechen, aber dort reagiert KODI sehr empfindlich wenn in den EDID-Daten die per HDMI angeliefert werden, Murks drin steht oder diese nicht richtig interpretiert werden können. Außerdem gibt es noch einen weiteren Bug der gerade behoben wird, welcher z.B. eine falsche Kanalzuordnung bei LPCM 7.1 verursacht. Dies betrifft allerdings das Aushandeln der Kanalzuordnung mit ALSA.
In der Vergangenheit gab es dort auch schon solche Effekte wie Du sie beschreibst, sie zeigten immer irgendwie Richtung EDID-Daten.

Hinweis: Bei Ton-Formaten die per pass-through zum AV-Receiver gelangen tritt dieser Effekt selten zu Tage, da die Kanalzuordnung erst im Receiver stattfindet.

Du kannst ja mal das Debug Logging aktivieren, eine betroffene Datei anspielen und den Link zum Log hier posten. Eventuell sieht man da mehr. Im Idealfall machst Du dies 1x mit Desktop und 1x nur mit SDDM für den direkten Vergleich.

Ich habe das jetzt nur auf RPi und PC probiert. Benutzt Du eventuell eine andere Plattform o. eine spezielle Distri ? Ich finde das interessant und würde es gerne mal sehen - vor allem was da bei mir dort an Infos noch so "vorenthalten" wird. Sowas hilft ja beim debuggen.
Kannst Du bitte einen Bildausschnitt davon anhängen?

@HY,

hast Du bei Dir zusätzliche Settings in der advancedsettings.xml aktiv, dass Du bei Aufruf der Player Debug Info (STRG + Umschalt/Shift (Pfeil oben) + O) zusätzlich File Cache Internals zu Gesicht bekommst? Bei mir zeigt er nur Durchsatzinformationen wie Kb/s für Audio, Mb/s für Video usw. an. Auch die Debug Log Anzeige (Strg + Umschalt (Pfeil oben) + D) bringt nur gesamten Speicherverbrauch zu Tage, was keine Rückschlüsse auf den Maximalverbrauch des File Caches zulässt.

@HY,

Zitat

In der GUI ist es übrigens bereits der komplette Verbrauch berechnet.

wie kommst Du zu dieser Annahme? Der Default war und ist 20MiB und wird auch so in der GUI angezeigt. Da durch den Umzug in die GUI das Verhalten selbst nicht verändert wurde, ist der Faktor 3 immer noch anzunehmen.

Bei mir wird in der GUI 20MiB angezeigt, analog zu den Bildern in dem GitHub Link. Wird bei Dir stattdessen 60MiB angezeigt?

Laut Deinem Post mit Deiner advancedsettings.xml hattest Du bisher 300MiB eingestellt. Auf der von mir verlinkten KODI-Wiki-Seite wird erklärt: man muss diesen Wert mal 3 nehmen und erhält damit den ungefähren zusätzlichen RAM-Verbrauch für das Caching.

314572800 Byte / 1024 / 1024 = 300MiB * 3 -> 900MiB !

Da KODI auch auf recht kleinen Systemen zum Einsatz kommt, ist der Default bei 20MiB. Mit 3 multlpliziert ergibt das also 60MiB und sollte keine Probleme verursachen.

Deine bisherige Einstellung 300MiB verursacht ein deutlich größeren Fußabdruck von 900MiB. Auf einem System mit nur 1GiB RAM würde ich das tunlichst lassen. Auf einem System mit 4GiB oder mehr, sollte das den Betrieb von KODI nicht unbedingt stören. Sofern diese Menge überhaupt notwendig ist. Wieviel RAM hat denn ohne Caching die Shield frei?

Im Beispiel 4 auf der Wiki-Seite wird pauschal angenommen, mit folgenden Einstellungen auch die schlimmsten Konstellationen abzudecken ohne zu viel RAM für den Cache zu verbrauchen:

• 128MiB ( entspricht 384MiB Verbrauch)
• Lesefaktor 20
• Alle Dateisystem zwischenspeichern, inklusive lokaler Dateien