Hallo zusammen,
auf Nachfrage von vanhofen, möchte ich euch eine größere Serie von 12 Commits vorstellen, die den Umgang mit Einstellungen in Neutrino grundlegend umbaut. Sichtbar ändert sich auf den ersten Blick wenig, die Menüs sehen aus wie vorher und alle Texte sind gleich geblieben. Unter der Haube ist aber fast jede Einstellung neu verdrahtet. Hier erkläre ich, was umgebaut wurde, warum, und was ihr davon habt.
Vorweg: die CoreAPI
Mit NI-Web ist unter src/coreapi eine eigene Schicht entstanden. Sie liegt zwischen der Box (Zapit, Sectionsd, Timerd, Treiber, Einstellungen) und allem, was die Box bedienen möchte. Kanäle, EPG, Timer, Aufnahmen, Wiedergabe, Speicher, Plugins, System und Einstellungen werden dort einmal beschrieben und für alle gleich angeboten.
Ihre Konsumenten sind:
- NI-Web: die REST-API unter /api/v1 und das neue Webinterface
- der MCP-Server: über ihn können KI-Assistenten die Box bedienen, mit Rechten je Verbindung
- die alte /control-Schnittstelle: Plugins und Skripte sprechen sie weiter über Loopback an
- die GUI selbst: mit dieser Serie zumindest für (fast) alle Einstellungen
Früher lag das Wissen, was eine Aktion bedeutet, beim jeweiligen Aufrufer: im Menü-Code, in nhttpd und y-web, in Skripten. Jeder neue Zugang musste dieses Wissen nachbauen, und jede Kopie lief mit der Zeit auseinander. Die Folgen kennt ihr: Das Webinterface prüft eine Einstellung anders als das Menü, oder eine Änderung wird zwar gespeichert, aber nie wirksam. Eine gemeinsame Schicht ist die einzige Stelle, an der man eine Regel einmal festlegt und für alle durchsetzt. Sie trennt außerdem die Darstellung (Fernseher, Browser, KI) von der Box-Logik, sodass Hardware-Wissen nicht mehr im Bildschirm-Code steckt.
Das Problem bei den Einstellungen
Die CoreAPI kannte schon jede Einstellung für Web und MCP: Schlüssel, Typ, Standardwert und Bedingungen. Die Setup-Menüs kannten dasselbe noch einmal, mit eigenen Wertelisten, eigenen Grenzen und eigener Hardware-Abfrage. Zwei Wahrheiten also, die zwangsläufig auseinanderliefen.
Schwerer wog etwas anderes: Ob eine Einstellung überhaupt wirkte, entschied allein der Menü-Code, der sie geändert hatte. Kam der Wert auf anderem Weg, etwa aus dem Web, über MCP, aus einem geladenen Backup oder beim Zurücksetzen, landete er oft nur in der Datei und sonst nirgends.
Was umgebaut wurde
1. Die Deklaration ist die einzige Quelle.
Jede Einstellung ist genau einmal beschrieben: Typ, Standardwert (auch je Box), Werteliste, Grenzen, Einheit, benannte Werte wie „aus“ oder „unbegrenzt“, Bedingungen, Kopplungen und Hinweistexte. Dazu gehören jetzt auch 56 Tastenbelegungen, 19 Theme-Farben und 3 Display-Farben sowie Listen von Einträgen.
2. Die Menüs werden aus der Deklaration gebaut.
Aus einer Zeile der Deklaration entsteht ein Auswahl-, Zahl-, Text-, Tasten- oder Farbeintrag. Rund 30 Setup-Menüs sind umgestellt, jedes einzeln gegen den alten Aufruf geprüft. Menütexte und Bedienung bleiben, wie ihr sie kennt.
3. Die Hardware entscheidet in der CoreAPI.
Was die Box nicht kann, wird gar nicht erst angeboten, statt nur ausgegraut zu erscheinen. Die CEC-Modi kommen direkt aus der Hardware-Bibliothek statt aus einer abgeschriebenen Tabelle.
4. Regeln gelten für jeden Zugang.
Werte außerhalb der Liste oder der Grenzen werden abgelehnt, ebenso Schreibzugriffe, deren Bedingung nicht erfüllt ist. Geprüft wird gegen den Zustand nach der ganzen Anfrage, die Reihenfolge der Werte spielt also keine Rolle. Gekoppelte Werte wie Startkanal TV/Radio oder der Wetter-Ort werden nur gemeinsam geschrieben. Die Kindersicherung gilt für Menü, Web, API und MCP gleichermaßen.
5. Anwenden über Gruppen.
Jede Einstellung gehört zu genau einer Gruppe von Treiber- oder Daemon-Arbeit, die sie wirksam macht. Ein Schreibvorgang führt jede berührte Gruppe genau einmal aus, nachdem gespeichert wurde, egal wer geschrieben hat. Blockierende Arbeit (Skripte, hdparm, Neustart von LCD4Linux) läuft auf einem eigenen Worker und hält die GUI nicht mehr auf. Schlägt sie fehl, steht das im Log und die schreibende Web-Sitzung bzw. MCP-Verbindung bekommt einen Hinweis.
6. Der Build wacht darüber.
Prüfskripte lassen den Build scheitern, wenn eine Einstellung keine Gruppe hat, in zwei Gruppen steht, ein Menü auf eine unbekannte Einstellung zeigt oder ein umgestellter Eintrag vom alten Aufruf abweicht.
Was es technisch bringt
- Eine Quelle für Menü, Web, API und KI. Nichts kann mehr auseinanderlaufen.
- Eine neue Einstellung ist ein Eintrag in der Tabelle, das Menü, die Web-Seite und die MCP-Werkzeuge ergeben sich daraus.
- Das Settings-Schema für Web und MCP ist etwa halb so groß: Standardwerte werden weggelassen, gemeinsame Wertelisten nur einmal genannt.
- Mehrere Werte auf einmal werden einmal gespeichert und jede Gruppe läuft einmal.
- Mount, Unmount und Formatieren liegen in der Box-Schicht, die Gerätenamen prüft und das Label quotet, bevor ein Befehl die Shell erreicht.
- Die Startreihenfolge ist aufgeräumt: Zapping-Modus, Farbraum und Bildregler werden in der Decoder-Phase gesetzt, Sectionsd startet nach dem Einhängen der Laufwerke, die CEC-Entscheidung fällt früher.
- Einstellungen aus ni-web oder über einen KI-Assistenten wirken sofort. Viele taten vorher schlicht nichts.
- Ein geladenes Backup und das Zurücksetzen der Einstellungen werden ebenfalls sofort wirksam.
- Ihr seht nur Optionen, die eure Box auch wirklich kann.
- Die Box bleibt bedienbar, während im Hintergrund Skripte oder hdparm laufen.
- Die Rückfrage „Behalten oder zurück?“ bei Videomodus und Fernbedienung kommt genau einmal.
- Ungültige Werte in einer alten Konfiguration werden beim Laden in den gültigen Bereich gerückt.
- Der Startkanal ist eine echte Senderauswahl.
- Vor dem Speichern von Videomodus und Fernbedienung fragt NI-Web nach, weil es dort kein automatisches Zurück gibt.
- Ablehnungen nennen die betroffene Einstellung und wovon sie abhängt.
- Texteingaben sind auf die Länge und die Zeichen begrenzt, die die Box erlaubt.
- Fehler beim Anwenden erscheinen als Hinweis.
Ändert ihr eine Einstellung im Browser, während auf dem Fernseher das passende Menü offen ist, springt der Eintrag dort sofort auf den neuen Wert, und abhängige Einträge werden neu ausgegraut oder freigegeben. Umgekehrt aktualisiert sich NI-Web, sobald ihr am Fernseher etwas ändert. Nach jedem Speichern liest NI-Web die Regeln der Box neu, ausgegraute Zeilen stimmen also immer mit der Box überein. Auch die Display-Karten folgen den Einstellungen, und ein MCP-Client erfährt bei seiner nächsten Antwort, wenn eine Änderung nicht angewendet werden konnte.
Weitere neue Features
Light Mode für NI-Web
Hell, dunkel oder wie das System, wählbar im Anmelde-Menü neben der Schriftgröße und je Browser gespeichert. Der dunkle Modus ist unverändert.
Screenshots der Frontdisplays
Unter Jetzt → Fernbedienung gibt es für jedes aktive Frontdisplay eine eigene Karte: GraphLCD, sobald es eingeschaltet ist, und LCD4Linux, sobald es läuft und „Screenshots erstellen“ an ist.
Archiv mit der ganzen Medienbibliothek
Das Archiv in NI-Web und für MCP umfasst jetzt dieselben Verzeichnisse wie der Moviebrowser, inklusive Netzfreigaben. Eine Freigabe, die nicht antwortet, wird nach 2 Sekunden ausgelassen und blockiert nichts. Jeder Eintrag zeigt seine Quelle, und ihr könnt danach filtern.
MCP
Alle Werkzeuge werden immer angeboten und erst beim Aufruf geprüft. Ein Client, der seine Werkzeugliste nicht neu lädt, verpasst so keines mehr. Dazu kommen eine Übersicht, welche Bereiche eine Verbindung lesen und ändern darf, und ein Filter auf einzelne Einstellungen.
SD-Karten
SD-Karten werden als Datenträger angeboten und bekommen auf ARM-Boxen die hdparm-Optionen.
Gleich mit behobene Fehler
- Text-, Tasten- und Farbeinstellungen werden jetzt genauso angewendet wie Zahlen und Auswahlen.
- Die Kindersicherung ließ sich über die API umgehen.
- Eine CEC-Änderung im Standby schaltete den Fernseher ein.
- Die E4HDULTRA verlor im Standby den Zapping-Modus.
- hdparm: Geräuschpegel und Abschaltzeit kamen nie bei den Platten an, weil eine Prüfung verkehrt herum stand.
- SD-Karten wurden nicht als Datenträger angeboten, der interne Flash dagegen schon.
- Das Root-Gerät wurde über st_dev bestimmt und dabei mit Speicherkarten verwechselt.
- Eine Platte sdaa wurde für eine Partition von sda gehalten.
- Bild-in-Bild-Einstellungen erschienen auch dort, wo der Boxmodus kein zweites Bild erlaubt.
- Auf der Coolstream HD2 griffen die automatischen Videomodi auf Plätze zu, die die Box nicht hat.
- Ein neuer TV-Screenshot konnte ein Bild abschneiden, das gerade noch gesendet wurde.
- /control/standby schrieb das CEC-Flag aus dem Web-Thread statt über die GUI.
- Ein halb geschriebenes LCD4Linux-Bild konnte ausgeliefert werden.
Alles ist gebaut und mit den automatischen Tests geprüft, aber nicht auf jeder Hardware. Rückmeldungen sind besonders willkommen zu:
- LCD4Linux und GraphLCD (Layout- und Moduswechsel, Screenshots)
- hdparm mit vollem hdparm, mit Busybox und mit schlafender Platte
- SD-Karten und eMMC (Multibox SE, HD51, VU+ Duo)
- HDMI und CEC: Videomodus, Farbraum, Zapping-Modus, Standby und Aufwachen auf BCM- und HiSilicon-Boxen
- Archiv mit NFS- und CIFS-Freigaben, auch mit einer Freigabe, die nicht antwortet
