BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[fred_feuerstein]

Ich rufe die ohnehin nur über die IP auf.
und Auto-Migration habe ich gleich deaktiviert. Das sollte dann auch gemacht werden.
Und unabhängig davon, ein neuer scan an einem sixback findet dann trotzdem auch die Boxen des anderen sixback. Halt mit einem Status, dass sie zu einem anderen sixback gehören.
sind aber trotzdem in der Liste.
Deswegen der Vorschlag mit entweder White- oder Blacklist, in die man die jeweiligen IP Adressen der Boxen einträgt.

Aber am liebsten wäre es mir, wenn man alle meine Boxen mit einem sixback verwalten könnte. Vielleicht hat Dirk dazu noch eine Idee, evtl. längere abfragegzeiten oder timeouts oder so etwas.

[betateilchen]

Deswegen der Vorschlag mit entweder White- oder Blacklist, in die man die jeweiligen IP Adressen der Boxen einträgt.

Vermutlich würde sowas aber weit über das hinausgehen, was hinter dem eigentliche Konzept und der Zielsetzung von sixback steht. Installationen mit mehr als vier Soundtouch Boxen dürften eher nicht das typische Szenario sein.

[tostmann]

@betateilchen, @fred: Ja, zwei SixBack im selben WLAN gehen konfliktfrei — die Peer-Erkennung ist seit langem drin: ein SixBack fasst im Auto-Mode keine Boxen an, die ein anderer lebender SixBack verwaltet. Der Ablauf aus #164 (Gruppe 1 migrieren, Auto-Mode aus, dann Gruppe 2 am zweiten Stick) ist genau richtig, und fred macht mit IP-Zugriff plus deaktiviertem Auto-Mode schon das Richtige. Manuelles Migrieren übernimmt eine Box dagegen immer bewusst — das ist der gewollte Umzugsweg zwischen den Sticks.

mDNS stimmt: beide melden sich aktuell als sixback.local, da hilft nur der Zugriff per IP. Konfigurierbarer Hostname ist notiert. Die fremden Boxen tauchen beim Scan absichtlich mit ihrem Status auf — ein simples Ausblenden in der Ansicht (kein großes Verwaltungs-Feature, da bin ich bei betateilchen) ist ebenfalls notiert.

@fred zu "alle 9 an einem Stick": längere Abfragezeiten oder Timeouts helfen da leider nicht — die Grenze ist der Platz des Preset-Speichers im Flash, nicht das Timing. Das zu heben ist der schon erwähnte größere Umbau, für den ich kein Datum nenne; bis dahin ist die Aufteilung auf zwei Sticks der ehrliche Weg.

@betateilchen zum C5 nach "Update existing": kannst Du direkt nach so einem Update einmal kurz den Strom trennen (USB ab/an) und schauen, ob er dann kommt? Bei unseren C5-Boards im Labor bleibt das native USB nach dem Flash-Reset gelegentlich hängen, bis einmal Strom weg war — ein Fresh Install verdeckt das, weil man dabei ohnehin neu ansteckt und provisioniert. Wenn der Power-Cycle nichts ändert, ist es etwas anderes und ich schaue tiefer rein.

Noch ein Hinweis in eigener Sache: in den nächsten Wochen sind Schulferien — Antworten und Releases kommen daher etwas langsamer als zuletzt gewohnt.

[betateilchen]

die Peer-Erkennung ist seit langem drin: ein SixBack fasst im Auto-Mode keine Boxen an, die ein anderer lebender SixBack verwaltet.

Darauf würde ich aber (nach meinen Erfahrungen) nicht wetten...

@betateilchen zum C5 nach "Update existing": kannst Du direkt nach so einem Update einmal kurz den Strom trennen (USB ab/an) und schauen, ob er dann kommt?

Habe ich alles schon erfolglos getestet.
Können wir aber gerne nach den Schulferien nochmal genauer testen, es gibt ja einen Workaround.

[fred_feuerstein]

Also mit 8 Lautsprechern bei SixBack klappt es bisher ohne Probleme mit den Presets, also ohne "leere" Presets. Werde weiter beobachten und berichten
Version .34 ist installiert.

Den 9. Lautsprecher in meinem Netzwerk habe ich nun mit einem anderen Projekt laufen: Soundtouch Reborn (STR) https://st-reborn.de/de/
Hier wird ohne externen Server alles "auf" dem Lautsprecher abgelegt, incl. WebServer zur Steuerung etc., und einige weitere Möglichkeiten.

Somit kann ich das andere Projekt auch mit testen

[tostmann]

Danke fürs Gegentesten — das ist eine wichtige Rückmeldung. Schön, dass .34 bei Dir mit 8 Boxen bisher sauber durchläuft und die leeren Presets weg sind.

Kurz zum Hintergrund, warum das jetzt hält: Der Verlust kam nicht vom WLAN oder von der Anzahl der Boxen, sondern von einem abgebrochenen Schreibvorgang in den Preset-Speicher. Blieb ein Eintrag dabei halb geschrieben zurück, hat der Speicher ihn beim nächsten Neustart als ungültig verworfen — deshalb sah danach alles aus wie frisch und leer. Seit .34 wird jeder Preset-Stand in zwei getrennte Slots geschrieben, nach dem Schreiben zurückgelesen und verglichen, und erst dann auf den neuen Stand umgeschaltet. Ein abgebrochener Schreibvorgang kann den zuletzt gültigen Stand damit nicht mehr überschreiben.

Dein "weiter beobachten" ist trotzdem genau richtig — der Fehler kam ja nur alle paar Tage, sicher ist erst eine längere ruhige Phase. Falls doch nochmal etwas auffällt, wäre ein /api/status-Dump im Moment des Problems (also vor dem Reboot/Recovery) sehr hilfreich.

Und dass Du parallel STR laufen lässt und mittestest: super. SixBack zielt bewusst auf den einfachen Fall — bis rund fünf Boxen und die sechs Tasten zurück, ohne Cloud. Für größere oder speziellere Aufbauten ist es gut, dass es daneben noch andere Wege gibt.

[tostmann]

v0.8.35 ist raus. Zwei Sachen aus diesem Thread sind drin:

Hostname konfigurierbar. Zwei Sticks im selben Netz haben sich bisher beide als sixback.local gemeldet — mDNS-Kollision, und in der DHCP-Liste sieht man auch nicht, welcher welcher ist. Jetzt einstellbar über die Web-UI oder PUT /api/hostname; wirkt auf mDNS und den DHCP-Client-Namen. Validierung serverseitig (a-z, 0-9, Bindestrich — nicht am Anfang oder Ende; Großbuchstaben werden kleingeschrieben, max. 24 Zeichen, leer = zurück auf Default). Braucht einen Reboot, und die UI zeigt bis dahin an, dass noch einer aussteht — sie behauptet also nicht, der neue Name sei schon aktiv.

Einzelne Boxen ausblenden. Lässt sich je Box einzeln setzen. Die Box verschwindet dann aus der Liste und aus allen Auswahl-Dialogen (Zone, Stereo-Paar, DLNA-Browser, Group-Sync), und ihr Status-Polling entfällt damit auch — spart also nebenbei Netzwerk-Fan-out. Überlebt Re-Discovery und Reboot. Bewusst reine Anzeige-Sache: im Hintergrund bedient der Stick die Box weiter genau wie vorher.

Dazu noch drei Dinge:

Improv läuft jetzt auf beiden USB-Buchsen (16-MB-S3). Bisher legte ein Compile-Flag fest, ob der Provisionierungs-Handshake auf UART0 (Bridge-Chip) oder auf dem nativen USB-Serial-JTAG liegt — Boards mit nur einer Buchse und ohne Bridge brauchten deshalb ein eigenes Build-Target. Jetzt laufen zwei Improv-Instanzen parallel, und die Buchse, auf der zuerst ein vollständiges IMPROV-Magic ankommt, bekommt die Session. Gematcht wird bewusst auf das Magic und nicht aufs erste Byte: sonst sperrt ein offenes Terminal auf der einen Buchse den echten Host auf der anderen aus.

Die Anwendungs-Logs (Arduino-Serial) bleiben dabei auf UART0, da ändert sich nichts. Auf dem nativen Port läuft allerdings die IDF-Konsole mit, der Improv-Stream teilt sich die Buchse dort also mit Log-Ausgaben. Deshalb nachgemessen: 894 Improv-Frames unter Dauerlast, ~11 KB Konsolen-Ausgabe im selben Stream, kein einziger kaputter Frame. Geprüft per Checksumme und nicht per Frame-Suche — ein toleranter Parser meldet sonst fröhlich Erfolg auf einem Stream, an dem ein strikter Client erstickt.

Zwei bekannte Fälle stehen auch auf der Flasher-Seite: bei ~88 % kann der Browser in der Konsole ,,Error fetching current state: TIMEOUT" loggen — der Flash läuft normal weiter und wird fertig. Und selten kommen sich Konsole und Handshake auf dem nativen Port doch in die Quere, dann meldet der Browser ,,Improv Wi-Fi Serial not detected". In beiden Fällen: nochmal versuchen, oder die UART-Buchse nehmen.

Store-Schreibfehler sind jetzt sichtbar — Warn-Anzeige im Header, statt dass es erst nach dem nächsten Reboot auffällt. Gilt auch für die Speaker-Liste.

gabbo-Watcher (das HW-Tasten-Re-Arm für Spotify) prüft PSRAM zur Laufzeit statt zur Compile-Zeit: auf S3-Modulen ohne bestücktes PSRAM startet er gar nicht erst — dort gibt es dann folglich auch kein HW-Tasten-Re-Arm. Boards mit PSRAM sind unverändert.

Partitionen sind unverändert, also ganz normal per OTA installierbar.

Release-Notes · sixback.io