Beiträge von psychofaktory

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

Zitat von Lehmden1

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:

gededit

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.

Zitat von HarryH

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.

Zitat von HarryH

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.

Zitat von HarryH

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.

Zitat von Lehmden1

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.

Zitat von Lehmden1

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.

Zitat von psychofaktory

Angeregt 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?

Alles anzeigen

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.

Google vergibt die Zertifizierung ja nur an Geräte die relativ stark reglementiert sind. Bei Android-Geräten z.B. ja immer nur für ein bestimmtes Modell mit bestimmten Eigenschaften. Und auch dann z.B. nur so lange wieder Bootloader gesperrt ist, etc.

Das wäre bei Windows so ja garnicht ohne weiteres umzusetzen, da die Vielfalt an verschiedenen Hard- und Softwarekonstellationen ja gigantisch ist und obendrein nicht sichergestellt werden kann, dass die Benutzer keine unerwünschten Eingriffe vornehmen können.

Von daher wird Google solche Geräte wohl eher nicht zertifizieren. Mir ist zumindest noch kein entsprechendes Gerät bekannt.

Unabhängig davon kann es natürlich trotzdem Konstellationen geben wo Streaminganbieter Material das eigentlich nur auf L1-zertifizierten Geräten in 4K/HDR ausgegeben werden kann aufgrund anderweitiger Implementierungen die Wiedergabe solcher Inhalte innerhalb eines Browsers oder einer eigenen App dennoch ermöglichen.

Zitat von HeadbangerWacken

sp gehts mit DRM geschützen inhalten und Widevine L! auf R4/5

Hier bitte vorsichtig sein.

Was du beschreibst ist die Installation des Widevine CDM auf Systemen bei denen das nicht standardmäßig enthalten ist. Bei einigen Android-Geräten ist das z.B. vorinstalliert und auch in verschiedenen Browsern bereits integriert. Dort wo es im Betriebssystem enthalten ist kann Kodi darauf zurückgreifen und man muss nichts mehr nachinstallieren. Bei meinem Sony-TV (Android TV) ist das z.B. der Fall.
Bei Windows-Systemen oder Linux (u.a. auch LibreElec auf einem RPi) ist das nicht vorinstalliert. Man kann das CDM dann aber aus einem System bei dem es bereits enthalten ist extrahieren und so hinterlegen, dass Inputstream Adaptive damit arbeiten kann. Das Addon Inputstream Adaptive Helper lädt dazu z.B. ein ChromeOS herunter und extrahiert daraus die benötigten Bestandteile und legt diese dann entsprechend ab.

Das hat aber erstmal nichts mit der Widevine-Zertifizierung zu tun. Hier können nur von Google zertifizierte Systeme die über ein Trusted Execution Environment (TEE) verfügen das Sicherheitsniveau L1 erhalten. Ohne dieses ist die Wiedergabe von 4K-Inhalten zumindest bei Amazon nicht möglich:

FAQ

Prime Video Addon for Kodi Media Center. Contribute to Sandmann79/xbmc development by creating an account on GitHub.

github.com

Wenn dein TV dennoch 4K ausgibt, könnte das mit einem Upscaling zu erklären sein.

Zitat von HeadbangerWacken

64-bit capable ARM SoC devices including Raspberry Pi 4/5 have been switched from ‘arm’ to ‘aarch64’ userspace. Manual update in LibreELEC settings will not list LibreELEC 12.0 releases on switched devices as there are no matching arm images (only aarch64). You can manually update by placing a LibreELEC 12 release file (.tar or .img.gz) in /storage/.update and rebooting.

If using Widevine to access DRM protected streaming services like Prime Video, Netflix, etc. the Widevine CDN folder in /storage/.kodi/cdm on switched devices must be deleted before first use as the existing arm libraries do not work on aarch64 systems. On first use after deletion aarch64 Widevine libraries will be downloaded and installed.

Bei LibreElec wurde mit Umstieg auf Version 12 der Adressraum bei Raspberry Pi 4 und 5 von "arm" auf "aarch64" umgestellt. Die Anleitung die du gepostet hatte beschreibt nur, welche Anpassung nach dem Update erforderlich sind, dass Widevine CDM überhaupt wieder genutzt werden kann. An der Höhe des Sicherheitsniveaus das damit erreicht werden kann ändert das allerdings rein garnichts.

Da ich gestern erst meinen Raspberry Pi 3B (LibreElec 12.02) via Backup & Restore durch einen Raspberry Pi 5 (LibreElec 12.02) ersetzt habe kann ich das so auch bestätigen. Führt man die angegebenen Schritte nicht durch, können Widevine-geschützte Inhalte nicht mehr wiedergegeben werden.

Das Fleetwood Mac Album ist wirklich klasse.
Das und das "Live" von 1980.

Auch sehr sehenswert die Dokumentation "Fleetwood Mac - Zeitloser Pop" die im September auf Arte lief.

Habe selbst einen Samsung UE46B6000VP mit maximal Full-HD SDR Unterstützung aus 2009 und diesen mittels eines Raspberry Pi und LibreElec smart gemacht.

Die Bedienung erfolgt wie HDMI-CEC und einer Flirc Skip S1 und ist super bequem.

Unter LibreElec laufen alle Mediatheken und AmazonVOD, Disney+ und Netflix ebenfalls. Da der Fernseher ohnehin keine höheren Auflösungen unterstützt stört die fehlende Unterstützung für die 4K-Wiedergabe bei den Streaminganbietern nicht.

Youtube/Invidious läuft ebenfalls. Auch in Verbindung mit Sponsorblock.

Damit dürften also alle deine Anforderungen erfüllt werden können. Je nachdem was du für ein Raspberry-Modell nimmst Auch beim Preis.

Die Einrichtung der Addons ist natürlich etwas aufwändiger als einfach die jeweilige App unter Android zu installieren. Mir ist es die Mühe jedenfalls wert.

Zur Wiedergabe hochaufgelöster Videos wurde ja bereits genug geschrieben.

Etwas mehr Details wären hilfreich um hier weiterhelfen zu können...

• Unter welchem Betriebssystem läuft Kodi auf den Raspberry Pi 5
• was genau versuchst du zu erreichen?
• wie genau gehst du dazu vor?
• was genau ist dann das Fehlerbild?

Hier müssen noch 2 neue "Portierungen" nachgereicht werden:

Doom als Captcha:

DOOM® CAPTCHA

Prove you're human by playing DOOM

doom-captcha.vercel.app

Doom eingebettet in eine PDF-Datei:

It's Doom ... running in a PDF file

Knee-deep in the markup

www.theregister.com

Und diese etwas ältere hier bei der Doom auf einem Thermomix-Clon gespielt werden kann:

Aus der Community itrunsdoom auf Reddit: [OC] Made a Thermomix clone run Doom with a friend

Entdecke diesen Beitrag und mehr aus der Community itrunsdoom

www.reddit.com

Mal ein anderer Ansatz der dem Thread-Ersteller vielleicht zum gewünschten Ergebnis verhelfen könnte, wenn auch über einen ganz anderen Weg:

Gab es nicht mal die Möglichkeit MagentaTV, Waipu bzw. Zattoo in TVHeadend einzubinden?
Ich weiß leider nicht wie hier der aktuelle Stand ist und was im Einzelnen möglich ist oder nicht.

Aber wenn das noch möglich wäre, dann könnte das doch ein deutlich einfacherer Lösungsansatz sein.

Ich habe inzwischen einen Home Assistant Server am laufen und dort auch die Matrix-Integration eingerichtet.

Als Erfahrungsbericht kann ich weitergeben, dass das ganz hervorragend funktioniert.

Habe z.B. eingestellt dass ich eine Benachrichtigung via Matrix bekomme wenn das Fenster im Bad zu lange geöffnet ist und es draußen kalt ist.

Das wäre auch ein Ansatz. Allerdings würde ich dann ja unter Batocera nicht von den Vorteilen der NVMe profitieren können, was auch wieder schade ist.
Der Raspberry soll wie bisher auch hinterm Fernseher verstaut werden, wo aufgrund der Ambilight-Installation schon ne ganze Menge Kabel usw. verbaut sind. Daher möchte ich da möglichst nicht ständig ran müssen um da was umzustecken oder so.

Es soll wohl mit Hilfe von umpartitionieren und einem zusätzlichen Bootloader möglich sein neben LibreElec auch ein weiteres Betriebssystem zu laden. Ich stelle mir das so vor, dass nach dem Boot dann für einen festgelegten Zeitraum (z.B. 5 Sekunden) eine Auswahlmaske erscheint bei der ich dann wählen kann ob LibreElec, oder ein anderes System gebootet werden soll. Erfolgt keine Eingabe, lädt LibreElec.
Allerdings wird das nicht offiziell unterstützt. Und ob das auch funktioniert wenn anstatt einer SD-Karte eine NVMe eingesetzt wird, dazu konnte ich keine Informationen finden.
Mir stellt sich rein aus praktischen Gründen dabei auch die Frage ob so ein Auswahlbildschirm des Bootloaders dann überhaupt eingaben von einer Fernbedienung via CEC annehmen würde.

Da sind also leider noch sehr viele Unbekannte in der Gleichung...

Das ist richtig.
Aus Kompatibilitätsgründen möchte ich aber (ähnlich wie Lehmden1 ) auf LibreElec als Basis für Kodi setzen.

Außerdem soll Kodi definitiv das Hauptsystem werden das standardmäßig ausgeführt wird. Retrogaming gibts nur gelegentlich und wird dann nur bei Bedarf gestartet. Von daher wäre es umständlich jedes Mal erst Batocera laden zu lassen um dann von dort aus Kodi aufzurufen.

Angeregt 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?

Zitat von RextheC

Smarthome scheint mir ja voll "easy" zu sein.

Plug'n'Play wie immer halt

Im Ernst: Ich hatte mir das als vollkommener Smarthome-Newbie auch deutlich einfacher vorgestellt.
Aber letztlich war es ein super Einstieg in das Thema weil ich gleich mit vielen Dingen konfrontiert wurde und dadurch sehr schnell viel lernen konnte. Und zugegenermaßen habe ich auch meine Freude an solchen Herausforderungen.

Sicher ist das nichts für jedermann und die meisten Leute würden wahrscheinlich eine viel simplere Variante bevorzugen. Dafür habe ich jetzt aber auch eine sehr komfortable Lösung mit der wirklich alle meine Anforderungen zur vollsten Zufriedenheit umgesetzt werden konnten.
Ich denke das unterscheidet im Kern einen Nerd vom Rest der Welt

Zitat von goscho

Was mich bisher immer gewundert hatte, war, dass bei einigen Räumen die Heizung bei geöffneten Fenster nicht aufhörte zu heizen.
Jetzt habe ich in den Einstellungen unter "Window Management" von "Turn off" auf "Frost Protect" gestellt.
Seither klappt es auch, dass die Heizungen aufhören zu ballern, wenn das Fenster im Bad nach einem Klogang zum Lüften geöffnet wurde.
Möglicherweise wird der "Off"-Status der Thermostate nicht korrekt übermittelt.

Jetzt habe ich extra für Dich mal in meiner Schublade gekramt und dort tatsächlich noch einen Aqara T1 Fensteröffnungs-Sensor gefunden den ich mir vor 2 Jahren mal zum rumprobieren erster Schritte im Smarthome angeschafft hatte.
Hab das Teil via Zigbee2MQTT in Homeassistant angelernt, umbenannt und dem Versatile-Thermostat fürs Bad zugeordnet. Als Einstellung dann die Standardeinstellungen belassen: "Turn off" nach 30 Sekunden.
Als ich das Fenster dann für 30 Sekunden offen hatte wurde das Thermostat von der Steuerung brav ausgeschaltet. Nachdem das Fenster anschließend wieder für mehr als 30 Sekunden geschlossen war sprang die Steuerung wieder zurück zu meinem voreingestellen Preset "Comfort".
Funktioniert bei mir also genau so wie es soll.

Zum Test dann nochmal das gleiche Mit "Frost Protection". Auch das hat funktioniert wie gewünscht.

Wie gesagt: Durch Transcoding wirst Du hier auch nichts gewinnen können.
Transcoding ist nur vom TVHeadend-Server zum Client (PVR-Pluging in Kodi, IPTV-App, Browser oder ähnliches) möglich. In meinem Szenario muss aber das SAT-Signal vom SAT:IP-Server erst über den VPN-Tunnel zum TVHeadend-Server transferiert werden. Und das geht nur RAW. Das war an der Konstellation hier ja auch die Besonderheit bzw. der Grund für den Thread.

Von Transcoding profitierst Du nur wenn SAT:IP-Server und TVH am gleichen Standort sind und das Endgerät mit dem dann konsumiert werden soll an einem entfernten Standort ist.
Sind SAT:IP-Server und TVH an entfernten Standorten hilft nur ausreichend Bandbreite zu haben.

Ja, leider müssen halt die Fülldaten mit übertragen werden.

Als die Bandbreite an dem Standort mit dem Digibit noch bei 50/10 MBit/s lag hab ich aber auch bei den HD-Sendern deutliche Unterschiede feststellen können.
Z.B. war eine Übertragung des ARD-/ZDF-Mittagsmagazin über ZDF HD problemlos möglich während es über Das Erste HD zu Rucklern kam.
3SAT HD sowie BR Fernsehen Nord HD liefen auch nicht flüssig. BR Fernsehen Süd HD hingegen schon.
Seit dem Upgrade der Bandbreite gibts hier aber bei allen Sendern keine Probleme mehr.