Beiträge von HarryH

Bei den Geräten zur Akku-Ladung und Diagnose kann ich leider nicht wirklich weiterhelfen, da bin ich nicht auf dem Laufenden. Wenn das MC3000 einem 132€ Wert sein muss um derartige Funktionalität zu erhalten, wird es sicherlich schwierig in dieser Preisregion ein adäquates Gerät für Akku-Packs zu erwerben. Den Hang es technisch ordentlich anzugehen kann ich voll und ganz nachvollziehen. Bei mir geistern zu wenig Akkus im Haushalt herum, dass sich diese Investition amortisiert.

Da Du danach als Anhaltspunkt gefragt hattest: Ein Squeezebox Radio ist direkt beim Abziehen des Hohlsteckers (Netzteil) ausgegangen. Da wollte ich schon lange den Akku ersetzen. Das andere hat bei 22% Lautstärke und guter WLAN-Verbindung 8,5h Stunden durchgehalten. In der Zeit fand keine weitere Interaktion mit dem Radio statt, es spielte dauerhaft den selben Sender.

Du kannst auch die jeweilige Squeezebox um ganz sicher zu gehen einmal komplett stromlos machen (Akku abziehen). Ich hatte schon den Fall, dass sie sich komplett weggehangen hatte und dauerhaft der Meinung war, der Batteriezustand wäre niedrig.

Die Squeezeboxen haben eigentlich eine Ladezustandserkennung, vorausgesetzt ein kompatibler Nachbau des Akkupacks ist eingesetzt. Ich hatte mal einen erwischt der wurde heiß (vermutlich Überladung), da die 2 Ladespannungen (Akku vmon1 / Akku vmon2) zu finden unter "Einstelungen -> Erweitert -> Diagnose -> Power" völligen Murks angezeigt haben (Abgriffe am Akkupack anscheinend falsch verdrahtet). Natürlich hilft dies nicht gegen Langzeit- und Alterungseffekte. So ein Feature: "Lade nur bis 80% und erst erneut wenn Du unter X% gefallen bist." gibt es hier leider nicht. Auch darf man nicht vergessen, dass die Elektronik in die Radios auch gealtert ist und ggf. Mist misst und zu früh die Meinung vertritt "Akkustand niedrig, lieber Herunterfahren."

Ich nehme an, getauscht hattest Du die Akkus schon? Oder sind das noch die ersten?

buers ,

für den genannten Einsatzzweck von OOmatrixOO bzw. tom06_09 , bietet sich auch noch nvram-wakeup an, sofern rtcwake als Nachfolger das nicht sowieso per ACPI schon abbildet. Kommt anscheinend aus dem VDR Projekt und ist genau dafür gemacht.

In anderen Fällen (z.B. Firmen) löst man sowas auch pragmatisch: Im eigentlichen Sinne geht es ja darum Serverdienste (Unraid) zu einem bestimmten Zeitpunkt zur Verfügung zu stellen.

Wenn man z.B. ganzjährig erreichen will: Fileserver erreichbar ab 08:00 lokaler Zeit, hinterlegt man im BIOS/UEFI 05:50 UTC als Einschaltmoment. Außerhalb der Sommerzeit würde Unraid schon ab 06:50 Uhr einschalten, aber der eigentliche Zweck wäre erfüllt. Ob jetzt die 1 Stunde zusätzlicher Stromverbrauch/Verschleiß den restlichen Aufwand rechtfertigt, muss jeder selbst für sich entscheiden. Für das Herunterfahren kann man das nach dem gleichen Muster handhaben, falls es keinen flexiblen Trigger/Timer dafür gibt.

buers ,

eventuell hast Du das Zünglein an der Waage schon herausgelesen. Ob der Fehler/Vorgang für den Anwender "spürbar" (sofort sichtbar) auftritt hängt von ein paar Randbedingungen ab.

• Ist man restriktiv unterwegs und erlaubt dem alten Windows keinen Netzwerkzugriff, tritt es zu 100% auf
• startet man Windows zuerst nach der Zeitumstellung und Linux erst danach, aktualisiert der Zeitsynchronisierungsdienst im Linux die Zeit bevor die graphische Anzeige dem Nutzer ersichtlich wird, in den Logs sollte man den erneuten Zeitsprung dennoch sehen.
• startet man Linux zuerst, hängt es davon ab wie schnell Windows den Kontakt zum Zeitserver sucht und ab wann der Netzwerkzugang (WiFi) besteht um die falsche Uhrzeit zu korrigieren. Schaltet man den PC ein und geht noch schnell eine Kaffee holen o.ä. kann das in der Zwischenzeit schon erfolgt sein. In den Windows Systemlogs sollte der erneute Zeitsprung aber ebenfalls zu finden sein.
• Sind alle Betriebssystem auf UTC eingestellt, sollte im Idealfall keines der Bootlogs/Systemlogs Zeitsprünge aufweisen. Außer man hat genau im fraglichen Zeitfenster 2 - 3 Uhr den PC an bzw. in diesem Moment hochgefahren.

ntpd ist bei vielen Distribution schon lange durch Alternativen (chrony, systemd-timesyncd o.ä.) ersetzt worden. Diese haben meines Wissens nach dieses 1000 Sekunden Limit nicht bzw. synchronisieren hart 1x beim Servicestart. Dies wurde besonders wichtig für Geräte wie Raspberry Pi die ab Werk keine Echtzeituhr besitzen. Damit man dort brauchbare Bootlogs generieren kann, bedient man sich meist eines Tricks und schreibt den aktuellen Zeitstempel beim Herunterfahren in eine Datei. Beim nächsten Systemstart wird diese Zeit als Basis genommen, ansonsten das Build-Datum des OS oder 01-01-1970. Bei einem Herunterfahren länger als 20min. würde die Zeit immer zu weit weg für ntpd sein und das Uhrstellen grundlegend verhindern.

Lehmden1

Du kannst die logischen und technischen Zusammenhänge für Dich gern ausblenden / ignorieren. Es hält Dich niemand davon ab. Wenn Du Dich in Deinem Haushalt genauer umschaust, wirst Du noch viel mehr Geräte vorfinden die intern auf UTC gestellt sind - einfach weil es eine weltweit definierte/akzeptierte stabile Zeitangabe ist und genau dafür geschaffen wurde. https://de.wikipedia.org/wiki/Koordinierte_Weltzeit
Du hättest viel Spaß mit einem Smartphone oder anderem mobilen Gerät, wenn es kein UTC als Zeitbasis hätte.

Das Einschaltproblem mit Unraid (PS: NAS & Co. zählt zu den Servern) ist unabhängig von der MEZ/MESZ vs. UTC-Thematik, denn die 1h Versatz über Nacht kommt in beiden Fällen zum Tragen. Die Hardwareuhr ist ein simpler Zähler der weiterläuft und interessiert sich nicht für Zeitzonen/Daylight Besonderheiten. Das ist auch die Ursache weshalb ein parallel installiertes Windows oder Linux ein 2. Mal an der Hardwareuhr "herumspielt", sofern MEZ/MESZ in der HW-Clock eingestellt ist. Das zuerst nach der Zeitumstellung hochgefahrene Betriebssystem erkennt, dass eine Änderung um 1 h stattfinden muss und zeigt diese dem Nutzer auch korrekt. Es setzt sich einen Flag im Dateisystem/Windows-Registry, dass dieser Wechsel stattgefunden hat und schreibt beim Herunterfahren die lokale Zeit in die Hardware-Clock. Das Problem: Im BIOS/UEFI wird der Daylight-Flag nicht hinterlegt. Das Betriebssystem welches danach gestartet wird und nicht dem ersten entspricht, weiß von der schon erfolgten 1h-Korrektur in der Hardware-Clock nichts und versucht es für sich erneut und vermerkt dies in den eigenen Betriebsystem-Einstellungen. Das Spiel geht solange, bist Du mit allen installierten Betriebssystemen 1x herum bist.

Wie schon erwähnt, das einzige was das durchaus kaschieren kann, ist ein einmalige erfolgreicher Abgleich mit einem NTP Server (übrigens mit UTC als Basis) direkt beim Hochfahren kurz nach der 1h Korrektur des Betriebssystems. Betreibt man z.B. noch ein älteres Windows wie XP o. Windows 7 ohne aktiven Netzwerkzugriff, gibt es keinen korrigierenden NTP Server und das Windows erkennt nur "Ah, da war doch Zeitumstellung seit dem letzten Hochfahren, also stell ich mal die Uhr um." Es weiß nichts davon, dass vorher die parallel existierende Windows 10/11 Installation das schon erledigt hatte!
Mit UTC als Basis in der Hardware-Clock passiert das nicht. Die Betriebssystem fahren genauso hoch wie bei lokaler Zeit in der Hardware-Clock, stellen dann aber nicht mehr an der Hardware-Clock herum, sondern "präsentieren" dem Nutzer die Uhrzeit immer korrekt mit der Differenz passend zur eingestellten Zeitzone.

Technisch richtig wäre in der genannten Konstellation des TE beim Herunterfahren zu prüfen ob der nächste Aufwachtermin nach einer Zeitumstellung liegt oder nicht.

• liegt der nächste Aufwachzeitpunkt nach einer Zeitumstellung, dann Aufwachzeit korrigieren
• liegt er davor, keine Änderung

Es gibt kommerzielle Produkte die sowas beachten und beherrschen, wäre die Frage ob es für Unraid ein ähnliches Skript für den vielfältigen BIOS/UEFI-Jungle gibt.

Das Verhalten alternativer Betriebssysteme an das von Windows anzupassen ist kein guter Ansatz. Spätestens bei der nächsten Zeitumstellung verstellt das Windows die Hardwareuhr. Sollte eine 2. Windowsinstallation vorhanden sein und wird danach hochgefahren, macht diese es ein weiteres Mal. Ein dahingehend manipulierte Linux-Installation ebenso. Es ist sinnvoller den von Linux vorgeschlagenen Standard: UTC zu verwenden, dann ist keine Manipulation der Hardwareuhr notwendig, außer sie geht wirklich mal vor/nach.

Manchmal kaschiert ein erreichbarer NTP Server die doppelte Verstellung durch Dual-Boot, aber oft geht das auch schief. Beispiel ntpd: Zeitserver die mehr als 1000 Sekunden von der eigenen Uhrzeit abweichen werden als ungültige Zeitquelle deklariert und verworfen. Dadurch bleibt eine völlig falsch gestellte Uhr auch unkorrigiert.

Unsere Zeitzone inkl. Sommerzeitumstellung ist nur eine datumsabhängige Addition zu UTC. Das bekommt jedes vernünftige Betriebssystem von allein hin, es muss nur wissen, dass die HW-Clock (BIOS/UEFI) auf UTC läuft und unterlässt dann unnötige Manipulationen. Selbst Windows beherrscht das seit einigen Generationen, man muss es nur einmalig per Windows-Registry setzen und die Hardwareuhr im BIOS/UEFI auf UTC stellen:

Windowspage - Datum und Uhrzeit - BIOS/CMOS-Zeit als UTC-Zeit festlegen

Stellt man seine Windowsinstallation so ein, ist auch Dual/Multi-Boot völlig problemfrei bei jedweder Zeitumstellung.

Den einzigen Komfort den man dabei verliert, im BIOS/UEFI die Zeit in der lokalen Zeizone angezeigt zu bekommen. Aber selbst das könnte sogar vereinzelt schon funktionieren mit den ganzen lokalisierten graphischen UEFI-Oberflächen.

Das 15W Netzteil des RPi4 kann für einige Einsatzfälle oder für erste Tests ausreichend sein. 12W ist ungefähr das TDP des RPi5 selbst, plus den Rest abhängig von RAM-Ausbau usw. Bei hoher Last und/oder zusätzlich angeschlossenen Komponenten (TV-Tuner, NVMe ...) muss deren Bedarf mit abgedeckt werden, daher das 5A Netzteil für den RPi5.

Mit dem Deaktivieren des USB Boots habe ich mich auf die Doku verlassen:

Zitat

• USB boot is disabled by default when connected to a 3A power supply. Set usb_max_current_enable=1 in /boot/firmware/config.txt to enable USB boot. Alternatively, you can press the power button a single time on a failed USB boot to temporarily enable usb_max_current_enable and continue booting. However, this setting will not persist after a reboot if enabled by pressing the power button.

Wenn Du zur Stabilisierung "usb_max_current_enable=1" setzen musst deutet es darauf hin, dass der RPi5 nicht die 5A via Power Delivery erkennt/gemeldet bekommt. Das kenne ich eigentlich nur bei ungeeignetem Netzteil oder Einsatz des Argon ONE V3 Gehäuses. Bei letzterem ist das technisch nicht besser gelöst, da der Controller(MCU) auf der Zusatzplatine mit dem Netzteil den Bedarf aushandelt - nicht der RPi5. Der RPi5 braucht allerdings diese Info, sonst geht er von max. 3A Leistung des Netzteils aus und beschränkt zusätzlich den USB-Strom und die Fähigkeit vom USB-Anschluss direkt zu booten wird dabei auch deaktiviert.

Solltest Du das Argon ONE einsetzen und Dein Netzteil kann die 5.1V/5A stabil liefern (Smartphoneladegeräte sind oft ungeeignet), dann muss das noch in die EEPROM/Bootloader Config.
PSU_MAX_CURRENT=5000

Hallo Voltmensch,

hier eine Version Deines Skripts für gpiod. Dafür muss das System-Tools Add-on ab Version 12.0.0.7 installiert sein. Was ich nicht weiß ob der Weg das Skript auf die Taste der Fernbedienung zu mappen in LibreELEC 12 noch genauso funktioniert oder ob da etwas geändert wurde. Für diesen Fall kannst Du zum Testen das Relais-Skript per SSH manuell ausführen: python3 /storage/.kodi/userdata/relais/relais.py Dort würde man auch sehen ob es eine Fehlermeldung gibt, falls z.B. ein anderer Prozess den GPIO Pin blockiert.

#!/usr/bin/env python3

import os
import sys

sys.path.append('/storage/.kodi/addons/virtual.system-tools/lib')
import gpiod

# this is the GPIO pin to enable the HDMI switch
RELAY_PIN=23 # GPIO23/PIN 16

# test for gpiochip numbering
if gpiod.is_gpiochip_device('/dev/gpiochip4'):
    # temporary RPi5 gpiochip assignment up to kernel 6.6.45
    # https://github.com/raspberrypi/linux/pull/6144
    chip = gpiod.Chip('/dev/gpiochip4')
else:
    # common
    chip = gpiod.Chip('/dev/gpiochip0')

try:
    # Set RELAY_PIN to input
    relay_config_in = {
        RELAY_PIN: gpiod.LineSettings(
            direction=gpiod.line.Direction.INPUT
        )
    }
    relay_pin = chip.request_lines(consumer="HDMI switch relay", config=relay_config_in)

    # Invert the current state of the RELAY_PIN, depending on input level (Pull UP/DOWN)
    if relay_pin.get_value(RELAY_PIN) == gpiod.line.Value.INACTIVE:
        # change RELAY_PIN to output and set it to high level
        relay_config_out = {
            RELAY_PIN: gpiod.LineSettings(
                direction=gpiod.line.Direction.OUTPUT,
                output_value=gpiod.line.Value.ACTIVE
            )
        }
        relay_pin.reconfigure_lines(config=relay_config_out)
    else:
        # change RELAY_PIN to output and set it to low level
        relay_config_out = {
            RELAY_PIN: gpiod.LineSettings(
                direction=gpiod.line.Direction.OUTPUT,
                output_value=gpiod.line.Value.INACTIVE
            )
        }
        relay_pin.reconfigure_lines(config=relay_config_out)

finally:
    relay_pin.release()

Für Deinen Einsatzfall kann man zwar auf gpiozero wechseln. Die erste Wahl ist es aber nicht (mehr), da es aufgrund immer noch unbehobener Bugs die Nebenwirkung haben kann die Ressourcen nicht wieder freizugeben. Besser ist lgpio oder idealerweise (lib)gpiod zu verwenden. Letzteres ist besser gepflegt aber etwas komplexer in der Umsetzung.

Dein Skript sieht für mich etwas "schräg" aus. GPIO Pin 23 soll als Ausgang agieren. Der Code in der Endlos-Schleife prüft ob der selbe Ausgang derzeit auf Low gesetzt ist und setzt ihn dann auf High und umgekehrt. Oder sollte der PIN ursprünglich toggeln? Auch der Aufruf von quit() zum Ausbrechen aus der Schleife ist ein nicht empfohlener Weg und macht den Einsatz einer Schleife an sich nutzlos. Hast Du eine bereits veränderte oder von ChatGPT bereitgestellte Version hier gepostet?

Im Skript selbst kann ich da keinen Bezug zur Fernbedienung erkennen. Hast Du das Skript auf eine bestimmte Taste gemapped?

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.

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.

Hi Raspi5Fan ,

das hat er schon umgesetzt. Sein Problem ist das hier:

Zitat

Allerdings habe ich an dem anderen Port auch nur eine lausige Auflösung von max. 768p.

Wenn wir mal annehmen die Verkabelung ist vermeintlich in Ordnung und es gibt bei Dir nur ein Timing/Kompatibilitätsproblem, kannst Du bitte das in der /flash/cmdline.txt an die boot Zeile anhängen und damit HDMI0 probieren?

video=HDMI-A-1:1920x1080@60D

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

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.

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.