An der ZIP-Struktur kann ich keinen Fehler erkennen.
In dem packages-Ordner war kein Eintrag mehr. Aber irgendwo lag da wohl doch noch was im Cache. Hab Kodi nun nochmal neu gestartet und die Installation des Addons lief jetzt wieder sauber durch.
Allerdings immernoch mit dem gleichen Verhalten wie zuletzt.
Edit: Die Kategorie könnte das Problem sein. Auf der Informationsseite des Addons wird als Kategorie "Medienquellen" genannt.
Nein, das klappt leider auch nicht.
Es bleibt bei dem gleichen Fehler wie eben. Ganz schön tricky.
Aber so:
Jetzt sagt mir Kodi dass die Installation fehlgeschlagen ist, wegen ungültiger Dateistruktur in der .zip-Datei.
Außer dem Inhalt der main.py wurde aber nichts geändert.
Und so?
Verhält sich ganz genauso.
Danke für die Unterstützung. Allein würde ich das definitiv nicht hinbekommen. Python is absolut nicht meine Welt stelle ich gerade fest.
Es sollte kein Problem darstellen, die geänderte "DialogButtonMenu.xml" irgendwo wegzuspeichern, bei einem Update den Estuary Skin ins Addon-Verzeichnis rüber zu kopieren und als letzten Schritt die weggespeicherte DialogButtonMenu.xml wieder raufzukopieren. Kann man sogar als Shellscript realisieren, da die Abarbeitungsschritte immer die Gleichen sind.
Nein, daran soll es natürlich nicht scheitern.
Meine Überlegung war jetzt nur welche Lösung am komfortabelsten und gleichzeitig wartungsarmsten ist, wenn das jetzt einmal umgesetzt wird.
Das ist lt. addon.xml ein Videoplugin und taucht daher keinesfalls unter Spiele auf: https://github.com/romanvm/plugin…ddon.xml#L9-L11
Neben der main.py, die Du so komplett so nicht nutzen kannst, ist dazu noch die addon.xml anzupassen.
Die addon.xml sowie die zugehörigen Ressourcen habe ich entsprechend eines anderen Spiele-Addons angepasst. Damit schaut das Optisch schon genauso aus wie ich das mir vorgestellt hatte und taucht auch unter dem Menüpunkt "Spiele" auf.
Den Code der main.py habe ich durch die beiden Zeilen oben ersetzt. Das Bash-Script wurde entsprechend der Anleitung ja bereits zuvor erstellt und funktioniert auch wenn es über das Ausschaltmenü angesteuert wird.
Bei der Variante über das Plugin funktioniert das Skript aber nicht. Stattdessen lande ich seltsamerweise mit dem Kodi-Dateimanager in der Batocera-Partition.
Vielen Dank SkyBird1980 und PvD für den pragmatischen Lösungsansatz, den ich auch sogleich ausprobiert habe.
Ergebnis: Das funktioniert schon mal!
Die von joschi77 vorgeschlagene Variante sieht auch vielversprechend aus. Hier sehe ich den Vorteil die Unabhängigkeit vom Skin.
Bei der Variante über das angepasste Ausschaltmenü dürfte bei einem Update von LibreElec (und damit wahrscheinlich auch dem Standard-Skin) die Anpassung verloren gehen.
Ich habe nun noch eine dritte Variante im Blick die mir hier sehr elegant erscheint, weil zum einen keine Abhängigkeit zum Skin bestünde, und der gewünschte Eintrag auch unter dem Menüpunkte "Spiele" auftauchen sollte.
Und zwar indem dieses Beispiel-Addon so angepasst wird, dass es nichts anderes macht als den Befehl für den Reboot in die Batocera-Partition zu geben.
Hier müsste ich nur wissen wie der Python-Code in der main.py für den Reboot in Partition 8 auszusehen hätte.
Wäre das in Python möglich?
Wäre es möglich ein ganz simples Addon dafür zu erstellen, dass nichts weiter macht als die Schaltfläche unter "Spiele" zu erstellen und bei Auswahl den gewünschten Befehl auszuführen?
Gibt es sowas evtl. schon?
Hallo,
ich habe eine Dualboot-Installation via P.I.N.N. mit LibreELEC und Batocera auf einem Raspberry Pi 5 am laufen.
Standardmäßig wird in LibreELEC gebootet. Um von dort aus komfortabel in die Batocera-Installation zu gelangen, gibt es (abhängig von den Partitionen auf denen sich die einzelnen OS befinden) einen einfachen Befehl.
Bei mir ist das reboot 8
Diesen Befehl würde ich nun gern als Eintrag/Kachel in Kodi unter dem Hauptmenüpunkt "Spiele" platzieren.
Wie kann das am besten bewerkstelligt werden?
Falls relevant: Skin ist Estuary.
Aber ich hatte wohl vergessen, dass tvh immer mpegts erwartet?
Das scheint tatsächlich so zu sein.
Das heißt das eigentliche Problem ist, dass TVH nur ein Streamformat akzeptiert, dass die gewünschte Funktion garnicht unterstützt.
Wäre schön wenn es hier einen Workaround gäbe.
pipe://ffmpeg -loglevel fatal -i http://usa5.fastcast4u.com:6332/stream/1/ -map 0 -c copy -metadata service_name=ChroniX\ GRIT -f mp3 pipe:1
Damit bekomme ich beim Scan leider einen Fehler:
2025-04-16 16:25:17.420 subscription: 004A: "scan" subscribing to mux "IPTV_Radio.m3u - ChroniX GRIT", weight: 5, adapter: "IPTV #1", network: "IPTV_Radio", service: "Raw PID Subscription"
2025-04-16 16:25:32.412 mpegts: IPTV_Radio.m3u - ChroniX GRIT in IPTV_Radio - scan no data, failed
Wieso willst du über tvheadend (statt direkt im Kodi IPTV Simple)?
Zum einen möchte ich die Senderliste zentral am TVH-Server verwalten und nicht an allen Clients einzeln, und zum anderen hatte ich in der Vergangenheit schon Probleme wenn mehr als ein PVR-Anbieter aktiv waren.
Hallo,
ich habe bei TVHeadend ein IPTV-Netzwerk angelegt das auf eine eigene .M3U-Datei verweist, die Streams zu verschiedenen Radiostationen enthält. Die Notation sieht dabei so aus:
#EXTM3U
#EXTINF:-1 tvg-name="ChroniX GRIT" group-title="Radio" radio="true" tvg-logo="https://fastcast4u.com/player/chronixg/_user/logo/c/chronixg/ch0.png",ChroniX GRIT
pipe://ffmpeg -loglevel fatal -i http://usa5.fastcast4u.com:6332/stream/1/ -vcodec copy -acodec copy -metadata service_name=ChroniX\ GRIT -metadata service_provider=Radio -mpegts_service_type advanced_codec_digital_radio -f mpegts pipe:1
Dann habe ich TVHeadend als PVR-Dienst in Kodi eingebunden, wo der Sender, den ich zuvor in THV als Kanal angelegt hatte, auch unter dem Menüpunkt "Radio" gelistet ist. Soweit alles wie gewünscht.
Wenn ich nun den Radiosender abspiele, wird mir aber nur der Titel des Senders angezeigt. Nicht aber Interpret und Titel des aktuell laufenden Songs. Diese Metadaten wären im ursprünglichen Stream (hier http://usa5.fastcast4u.com:6332/stream/1/) aber enthalten.
Wie kann erreichen, dass mir bei über TVHeadend bereitgestellten Radiosendern auch Interpret und Titel angezeigt werden?
Meine Vermutung ist, dass der TE ein Problem in seiner Netzwerkkonfiguration hat.
Wenn ich das über seine beiden Threads hinweg richtig verfolgt habe hat er einen DSL-Anschluss bei O2 und O2 liefert offenbar nur einen IPv6-Zugang.
Intern verwendet die vorhandene Fritzbox IPv4 und IPv6.
Jetzt fehlen mir für die weitere Eingrenzung des Fehlers einige Angaben. Ich weiß nicht wie die Fritzbox im Detail konfiguriert ist und auch nicht wie das O2 mit den IPv6-Präfixen handhabt.
Möglicherweise ändert sich bei der Zwangstrennung der vom Provider zugewiesene IPv6-Präfix. Wird dieser an die Clients delegiert, erhalten diese somit dann auch eine neue IP-Adresse.
In einem LAN in dem IPv4 und IPv6 gleichzeitig aktiv sind, nutzen viele Geräte standardmäßig vorrangig IPv6, bzw. bekommen die Clients bei Anfragen über IPv6 schneller die Antwort.
Bei einem IPv6-only Anschluss könnte es dann auch sein, dass bei Zwangstrennung und neuem Präfix die Fritzbox intern auch das Gateway zurücksetzt, was auch Auswirkungen auf die Clients haben kann die die ausschließlich intern genutzten IPv4-Adressen nutzen, da auch deren Internetzugriff über die Fritzbox letztlich über IPv6 ins WAN übergeht.
Als Lösungsansätze würde ich empfehlen:
Edit zur DNS-Thematik:
Die Fritzbox sollte die interne Namensauflösung übernehmen. Folglich sollte als DNS den Clients dann auch die IP der Fritzbox zugewiesen werden.
Damit auch externe Hostnamen aufgelöst werden können benötigt die Fritzbox (als einziger Client) einen externen DNS-Server. Für gewöhnlich weißt der Provider hier einen zu. Man kann aber auch selbst öffentliche DNS-Server angeben.
Würde man den Clients direkt die IP-Adressen der öffentlichen DNS-Server zuweisen, würde für die Clients zwar die Namensauflösung im Internet funktionieren, aber nicht im lokalen Netzwerk, da die öffentlichen DNS-Anbieter ja nicht die internen Geräte im Heimnetz kennen. Zudem würde man durch die Anfragen die Hostnamen seiner internen Geräte an die öffentlichen Server leaken.
Einen Sonderfall gibt es dann aber doch noch, der auch relevant sein kann wenn auf den Clients mit Hostnamen statt IP-Adressen versucht wird auf interne Netzwerkressourcen zuzugreifen: Manche Hersteller haben in ihren Betriebssystemen feste DoT- oder DoH-DNS hinterlegt. Auch bei Browsern gibts das. Damit werden verschlüsselte DNS-Anfragen direkt (und damit an der Fritzbox vorbei) an öffentliche DNS-Server gesendet. Die Clients haben dann keine Chance interne Namen aufgelöst zu bekommen. Die Hersteller machen das, damit die Kunden keine Möglichkeit haben DNS-basierte Werbefilter einzusetzen.
Die Telekom ist harmlos im Vergleich zu z. B. 1&1
Welche negativen Erfahrungen musstest du hier machen?
In dem ganzen Telekommunikationssektor kommt es mir vor als gibt es bei den Anbietern am Markt nicht den "Besten", sondern immer nur "das geringste Übel"...
Alternativen zur Telekom gibts hier - wie du schon schreibst - leider keine sinnvollen.
Ich war mal für ein paar Monate bei Vodafone, aber das war aufgrund des vollkommen überbuchten Netzes eine deutlich größere Katastrophe (statt 100 MBit/s kamen tagsüber nur 20 MBit/s und am Abend maximal 2 MBit/s an).
Da war ich dann auch mit der Bundesnetzagentur und der Verbraucherzentrale in Kontakt. Das ist dann aber alles wieder sehr mühsam und langwierig.
Grundsätzlich bin ich mit der Telekom auch sehr zufrieden. Klar, nicht die günstigsten, aber als Netzbetreiber ist bei netzseitigen Störungen die Störungsbeseitigung deutlich unkomplizierter und auf technischer Ebene passt das auch. Hier gibt es viele Optionen die die Telekom bietet bei anderen ja nicht.
Nur wenn sie zu aufdringlich mit der Werbung werden oder gar so ne Aktion wie hier bringen geht das garnicht.
Das die Nummer gespooft sein könnte hab ich schon immer im Hinterkopf. Hier war es aufgrund der Daten die vorgelegt werden konnte aber unwahrscheinlich dass es sich um einen Dritten handelt. Habe ich 2x direkt gefragt ob der Anrufer direkt bei der Telekom arbeitet und nicht "im Auftrag von" oder ähnlich. Beide Male hieß es sie wären direkt von der Telekom.
Wäre es tatsächlich ein Auftragnehmer der Telekom oder gar eine Dritte Partei gewesen, wäre das nochmal bedenklicher gewesen. Der Gedanke dass die Telekom ihre Kundendaten ungefragt an solche Anbieter weitergibt ist gruselig. Wenn auch leider nicht auszuschließen.
Hatte sogar mal in Fernsehberichten gesehen, das dort empfohlen wurde, nie das Wort "Ja" auf so einer Verbindung zu sagen, weil das dann schon mal zusammengeschnitten wird als Bestaetigung.
Dann hätte man vorher aber auch der Aufzeichnung des Gesprächs, oder Gesprächsabschnitts zustimmen müssen. Da wird normalerweise nach der "Verkaufsberatung" angekündigt dass die Aufzeichnung kurz gestartet wird, damit das "Ja" vermerkt ist und er Vertrag damit abgeschlossen ist.
dann frage ich sofort immer nach der Rueckrufnummer.
Grundsätzlich ein guter Tipp. Tatsächlich habe ich angesprochen, dass ich gerne etwas Bedenkzeit haben würde und mich zurückmelden wolle. Man bot mir daraufhin an mich 2 Stunden später nochmal zurückzurufen, damit ich es mir bis dahin überlegen könne.
Hier gibts auch nochmal ne gute Übersicht auf was man achten sollte, bzw. was man tun kann:
Bundesnetzagentur - Homepage - Schutzmöglichkeiten vor unerlaubter Telefonwerbung
Hallo,
ich möchte aufgrund aktuellen Anlasses an dieser Stelle mal auf eine Masche aufmerksam machen mit der die Telekom versucht Bestandskunden übers Ohr zu hauen.
Ich erhielt heute bereits 2 Anrufe von der Rufnummer 0800 0002983 auf meine Mobilfunknummer. Da meine Nummer praktisch so gut wie nirgends hinterlegt ist bin ich bei Anrufen von mir unbekannten Nummern sehr vorsichtig. Daher ging ich zwar ran, nannte aber erstmal keinen Namen. Der Anrufer nannte kurioserweise dann auch keinen Namen. Also wartete ich ab was passieren würde. Nach ca. 10 Sekunden Stille fragte ich dann wer dran sei und es meldete sich eine Stimme mit "Telekom Deutschland Bestandskundenservice" und fragte [ganz unspezifiziert] ob ich für den Festnetzanschluss zuständig sei.
Als ich daraufhin fragte um was es denn ginge teilte mir die Person mit, dass ich sicherlich bereits wüsste, dass aufgrund der neuen Gesetzesänderung die Verträge sich automatisch monatlich verlängern würden.
Die Telekom könne deshalb nicht mehr garantieren, dass sich nach Ablauf des jeweiligen Monats die Preise nicht erhöhen würden. Daher böte die Telekom ihren langjährigen Bestandskunden die Option an die Preise für ganze 24 Monate zu fixieren.
Dazu müsste ich nur mein Einverständnis am Telefon geben.
Ich fragte ob sie mir hier die Vertragsunterlagen vorab zur Durchsicht schriftlich zukommen lassen könne und bekam als Antwort: "Ja, ich kann Ihnen die Vertragsbestätigung" dann per Post schicken.
Nachdem ich weiter nachhakte ob ich denn nicht auch das Angebot via E-Mail bekommen könne damit ich es unterschreiben und beauftragen könne hieß es, es wäre eine reine Telefonaktion und ich müsste mich hier und jetzt entscheiden.
Mir war klar, dass das alles andere als seriös war, aber war neugierig wie das weiter gehen würde. Also erkundigte ich mich nach den Konditionen.
Aktuell gebe es an dem Anschluss ein VDSL100 für das monatlich 54,95 € gezahlt würden [tatsächlich liegt der Preis bei 47,95 €].
Sie könne mir nun anbieten den Preis für weitere 24 Monate zu fixieren. Dabei würde obendrein die Geschwindigkeit noch auf VSDL250 erhöht und es gäbe zusätzlich zur Festnetz-Flat noch eine Mobilfunkflat. Zudem in den ersten 3 Monaten noch 10 € Nachlass auf die Rechnung.
Effektiv wird also Versucht unter Vorgabe falscher Tatsachen den Kunden ein (nicht benötigtes) höherpreisiges Tarifupgrade aufzuschwatzen und gleichzeitig den Kunden für weitere 24 Monate zu binden. Das geht in meinen Augen garnicht!
Durch die Novelle des Telekommunikationsgesetzes die am 01.12.2021 in Kraft getreten ist, sind Telekommunikationsverträge mit einer Mindestlaufzeit von 24 Monaten zwar weiterhin möglich, verlängern sich dann aber nicht (wie früher) automatisch um weitere 12 Monate, sondern lediglich noch einen Monat. Das hat für Verbraucher keine Nachteile wie am Telefon suggeriert, sondern den Vorteil, dass Kunden schneller zu einem anderen Anbieter wechseln können. Die Vertragsbedingungen beim ursprünglichen Vertragsabschluss bestehen ansonsten fort. Also auch die Preise. Würde nun (wie in dem Gespräch angedroht) die Telekom die Preise zu Lasten der Kunden erhöhen, entstünde automatisch ein Sonderkündigungsrecht und man wäre ebenfalls nicht mehr an den Vertrag gebunden. Die Panikmache seitens des Bestandskundenservice ist also vollkommener Quatsch.
Zum Abgleich der Daten wurden mir dann noch bereitwillig sämtliche zu dem Anschluss hinterlegten Kontaktdaten mitgeteilt. Damit kam am Ende des Gesprächs heraus, dass ich überhaupt nicht der richtige Ansprechpartner war, da es sich um einen völlig anderen Anschluss handelte. Leider auch aus Sicht des Datenschutzes sehr bedenklich. Als ich meine offensichtlich falsch hinterlegte Mobilfunknummer bereinigen lassen wollte wurde dann beide Male aufgelegt.
Also: Seid vorsichtig und lasst euch nix andrehen ![[ad]](https://www.kodinerds.net/wcf/images/smilies/smiley41.gif "ad"){kind=small}
sobald LibreElec hochgefahren ist, wird per CEC auch der TV und der AVR eingeschaltet. Allerdings kommt es dabei gelegentlich zu einem HDMI Problem. Dann bleibt das Bild schwarz, nur der Ton ist zu hören.
Habe da eine ähnliche Konstellation wie du und das wie folgt gelöst:
TV und Raspberry hängen an einer Master-/Slave-Steckdose. Der TV ist der Master.
Wird der TV angeschaltet, schaltet die Steckdose auch den Raspberry an. Via HDMI-CEC wird dann automatisch auch der AVR aus dem Standby geweckt. Der hängt an einer separaten Master-/Slave Steckdose bei der er wiederrum Master ist und z.B. den aktiven Subwoofer als Slave startet.
Dabei bin ich auf ähnliche Bild-/Ton-Probleme gestoßen.
Nachhaltige Abhilfe war hier:
Das Herunterfahren läuft dann nach den gleichen Prinzipien, nur umgekehrt.
Der TV wird ausgeschaltet und Raspberry sowie der AVR bekommen via HDMI-CEC den Befehl herunterzufahren bzw. in den Standby zu gehen.
Die Master-/Slave-Steckdose ist dabei so eingestellt, dass die Slaves nicht sofort stromlos werden, sondern mit einigen Sekunden Zeitversatz. Das reicht um den Raspberry sauber herunterfahren zu lassen.
Bei mir hängt dazwischen dann noch ein HDMI-Splitter wegen Ambilight. Das macht für das zugrundeliegende Prinzip hier aber keinen Unterschied.
Achja: Essentiell war dabei die CEC-Einstellungen in LibreElec richtig zu setzen. Hier habe ich z.B. die physikalische HDMI-Adresse manuell gesetzt, und eingestellt, dass der AVR aufgeweckt werden soll sowie die Geräte beim Ausschalten des TVs herunterfahren sollen.
dann muss das noch in die EEPROM/Bootloader Config.
PSU_MAX_CURRENT=5000
Danke für den Hinweis.
Diese Einstellung hatte ich im Zuge der Anpassung an der Config.txt tatsächlich ebenfalls gesetzt. Das hatte ich oben leider nicht erwähnt.
deutet es darauf hin, dass der RPi5 nicht die 5A via Power Delivery erkennt/gemeldet bekommt. Das kenne ich eigentlich nur bei ungeeignetem Netzteil
Das passt tatsächlich auch exakt zu meinem Anwendungsfall.
Der RPi5 wird von dem großzügig dimensionierten Schaltnetzteil mitversorgt, dass auch das Ambilight speist. Das kann natürlich kein Power Delivery.
und die Fähigkeit vom USB-Anschluss direkt zu booten wird dabei auch deaktiviert.
Das kann ich hingegen nicht bestätigen. Bei meinen Vorbereitungen und im Rahmen der Fehlersuche bei den Bootproblemen habe ich den Raspberry auch an dem offiziellen Raspberry 3A Netzteil vom RPi4 betrieben und konnte in der Konstellation auch problemlos von einem USB-Stick booten.
Mit 99,99% Wahrscheinlichkeit hat irgendwo ein Kontakt nicht so gesessen wie er eigentlich sollte.
Das ist auch meine Vermutung. Mehrere Sichtkontrollen konnten den Fehler aber zumindest nicht erkennen.
Immerhin hat die bewährte Methode alles mal auf Null zu setzen und Stück für Stück zu testen dann ja funktioniert.
merkt man ja nichts davon, das er eigentlich ein Bastel- Computer ist.
Jetzt hab ich doch mal eben geschaut: Tatsächlich bastel ich schon seit 2014 mit Raspberries und hab mit allen bisher erschienenen Generationen bereits vielfältige Projekte umgesetzt.
Mir macht das auch großen Spaß solche individuellen Zielsetzungen dann jeweils umgesetzt zu bekommen. Vor allem wenns eben keine Lösungen von der Stange sind, am Ende dann aber genau das passende für meine Anforderung rauskommt.
Hier gabs neben dem Upgrade von einem Raspberry Pi 3 B+ und SD-Karte auf einen Pi 5 mit 8 GB RAM mit einer M.2-SSD auf einem NVMe-HAT die zusätzliche Herausforderung Batocera im Dualboot zu installieren und obendrein noch ein Ambilight lauffähig angeschlossen zu bekommen.
Das ist letzten Endes auch alles gelungen. Aber die Menge an Stolpersteinen die im Weg lagen war schon ziemlich groß diesmal.
Falls jemand ein ähnliches Vorhaben hat hilft dieser Erfahrungsbericht vielleicht die ein oder andere Fehlerquelle zu umschiffen.
Alles anzeigenAngeregt durch diesen Beitrag hier und weil ich mir schön öfter eine flüssigere Bedienung sowie mehr Leistung beim Retro-Gaming gewünscht habe möchte ich nun auch von meinem bisher genutzten Raspberry Pi 3B (1GB) auf den Raspberry Pi 5 (8GB) upgraden.
Als Betriebssystem soll LibreElec 12.0.1 genutzt werden wie bisher auch. Ich bin am überlegen, ob es nicht sinnvoller wäre das Retrogaming vom in Kodi integrierten Retroplayer auf eine dedizierte Installation von Batocera zu verlagern.
Via GPIO muss außerdem noch ein bereits vorhendenes DIY-Ambilight angeschlossen werden.
Wäre die hier genannten Komponenten für mein Vorhaben immernoch die vorrangige Empfehlung?
Wäre ein Dualboot mit LibreElec und Batocera in der Konstellation möglich?
Zwischenzeitlich konnte ich mein Vorhaben auch umsetzen und möchte euch den Erfahrungsbericht dazu nicht vorenthalten.
Eingesetzt wurden die im Eingangspost vom Lehmden genannten Komponenten zusammen mit einen Raspberry Pi 5 (8GB). Als SSD sollte es eine WD Blue SN580 NVMe (500 GB) werden.
Die SSD sollte an sich mit dem aktuellsten Bootloader auch kompatibel sein.
Der Zusammenbau war relativ unspektakulär. Lediglich mit dem Flachbandkabel hatte ich etwas Schwierigkeiten bis ich erkannt hatte wie der Verschluss am Stecker auf den Platinen funktioniert. An dieser Stelle war die Anleitung etwas dürftig.
Der Plan war dann mittels SD-Karte über den RPi-Imager den Bootloader zu aktualisieren. Dann die SSD über ein externes Laufwerk mit PINN (für den Dualboot) zu bestücken. Anschließend wollte ich die SSD dann auf dem Pi verbauen, PINN booten und dort dann LibreELEC und Batocera installieren, die Boot-Einstellungen entsprechend meinen Wünschen anpassen und die für mein Ambilight erforderlichen Anpassungen vornehmen. Soweit die Theorie...
In der Praxis bin ich bis zum Einbau der SSD in den Pi gekommen. Dann ging nichts mehr. Wortwörtlich. Der Pi ließ sich nicht mal anschalten. Keine LED kein Signal. Nichts.
Auch nicht mit einem anderen Netzteil.
Daraufhin war meine Vermutung, dass der Raspberry defekt sein muss und wollte ihn bereits zurückschicken. Als ich dazu alles auseinandergelegt hatte dachte ich mir ich könnte das Teil nochmal allein, ohne irgendwelche Peripheriegeräte testen. Und tatsächlich: Der Pi lief.
Also habe ich Stück für Stück wieder alle Teile montiert um zu sehen wo der Fehler liegt. Aber auch als alles wieder zusammengesetzt war lief der Pi noch. Ich weiß bis heute nicht wo der Fehler lag...
Das war allerdings noch nicht das Ende der Reise. PINN wollte einfach nicht booten. Offenbar wurde die SSD nicht erkannt. Trotz aktuellem Bootloader, aktuellem PINN und den erforderlichen Anpassungen an der config.txt. Von SSD lief das System hingegen. Kurioserweise wurde die SSD dort erkannt. Aber nur sporadisch.
Nach etwas Recherche fand ich den Hinweis, dass es helfen könnte auch die Eeprom-Firmware aktualisieren. Aber auch das brachte keine Verbesserung.
Reset des Bootloaders über den PRI-Imager, Neupartitionierung der SSD über Linux (über den externen SSD-Adapter); alles brachte keine Verbesserung.
Mein nächster Ansatz war daraufhin die Firmware der SSD zu aktualisieren. Also SSD an einen Windows-Rechner und dort die Firmware aktualisiert. Anschließend wieder der Versuch PINN von der SSD zu booten.
Wieder wurde die SSD nicht erkannt. Als ich die SSD dann wieder an den Linux-Rechner hing, konnten auf einmal auch dort die Partitionen nicht mehr gelesen werden. Auch unter Windows nicht mehr.
Um es etwas abzukürzen: Der (schon etwas ältere) externe SSD-Adapter den ich verwendet hatte, hatte augenscheinlich ein Kompatibilitätsproblem mit der neuen Firmware.
Also habe ich einen anderen SSD-Adapter beschafft. Nun wurde die SSD wieder sauber unter Windows und Linux erkannt. Am Raspberry aber weiterhin nur sporadisch.
Nach weiterer Recherche deutete alles darauf hin, dass der Controller der SSD anscheinend doch nicht mit dem HAT kompatibel war. Zum Test bestellte ich eine Kingston NV3 (500GB).
Damit lief der Boot von PINN zum ersten Mal reibungslos durch. Man muss hier wirklich aufpassen eine SSD mit dem richtigen Controller zu bekommen. Teilweise werden gleiche Modelle mit unterschiedlichen Controllern verkauft, oder auf den Modellen einer Serie mit unterschiedlicher Kapazität werden unterschiedliche Controller verwendet.
Das war allerdings auch noch nicht das Ende der Reise. PINN ließ sich zwar booten, und dort auch Libreelec und Batocera installieren. Der anschließende Boot von LibreElec zeigte dann aber nur ein seltsames Standbild an. Den Grund habe ich schnell herausfinden können: Das Image das in PINN geladen wird war nicht das aktuelle LibreElec 12.0.2 sondern noch Version 12.0.1 die diesbezüglich in Verbindung mit den noch relativ neuen Raspberry Pi 5 in der 8 GB Variante noch einen Bug hatte. Nachdem ich das System etwas hatte laufen lassen und dann neu startete wurde durch die automatische Updatefunktion in LibreElec dann die Aktualisierung auf die neuere Version durchgeführt und die Anzeige passte endlich.
Weiter gings mit dem Test von Batocera. Hier brach der Bootvorgang gleich zu Beginn mit einem Fehler ab. Sehr ernüchternd. Es folgte wieder eine Suche nach der Fehlerursache.
Auch hier war der Grund ein veraltetes Image, dass noch nicht mit dem neuen D0-Stepping der 8GB-Modell zurecht kam. Hier werde ich warten bis PINN dahingehend ein Update bekommt.
Unterm Strich läuft LibreELEC nun wie gewünscht. Auch beim Boot über PINN, was mir die Möglichkeit zum Dualboot mit Batocera eröffnet, sofern das zugehörige Image meine Hardware in Zukunft dann unterstützt. Geplant ist dann über eine Schaltfläche in LibreElec einen Befehl aufzurufen, der den RPi neu startet und Batocera lädt.
Auch Hyperion läuft sauber. Hier musste ich nur das usb_max_current_enable=1 setzen, damit die Verbindung zum externen USB-Grabber nicht immer wieder abbricht.
