BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[fred_feuerstein]

ja, scheinbar hatte ich das Update auf die .42 bisher nur bei meinem 2. SixBack im Büro gemacht...

nun aber auch auf meinem Hauptstick.

Das Handling nach dem Update/Reboot etc. ist aber 100Prozent gleich wie in Beitrag #222 von mir beschrieben.

Hier der Status nach dem Update und Reboot mit 1x Preset Save Fail.

Code Auswählen Erweitern

{
  "name": "SixBack",
  "version": "0.8.42",
  "build": "2026-08-07 13:56:43",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 4462,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -24,
    "channel": 5,
    "band": "2.4GHz",
    "mac": "1C:DB:D4:74:9F:44",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 111844,
    "min_free": 88904,
    "total": 339144,
    "largest_block": 52212,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8359648,
    "total": 8388608
  },
  "chip": {
    "model": "ESP32-S3",
    "cores": 2,
    "revision": 2,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.173:8000"
  },
  "speakers_count": 9,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 1,
    "speakers": 8,
    "save_heap_aborts": 0,
    "save_nvs_fails": 1
  },
  "inventory": {
    "save_fails": 0
  },
  "health": {
    "boot_count": 6,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 6,
    "last_wifi_down_s": 1,
    "last_reset": "SW",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": 262
  }
}

[tostmann]

Danke — damit ist es auf .41 und .42 dasselbe Bild, dein Fall bleibt also offen.

Was der Dump sagt: save_nvs_fails steht auf 1, save_heap_aborts auf 0. Es scheitert das Schreiben in den Flash, nicht der Arbeitsspeicher. Ob der Bereich schlicht voll ist, weiß ich noch nicht — das kann der Stick selbst beantworten:

Code Auswählen Erweitern

http://<dein-stick>/api/nvs/stats
Bitte einmal direkt nach einem Neustart und einmal unmittelbar nachdem das ✕ wieder den 500er gebracht hat. Interessant ist free_entries.

[fred_feuerstein]

hier direkt nach Neustart, noch vor dem Preset Save Fehler:

used_entries   494
free_entries   136
total_entries   630
namespace_count   15
percent_used   78.4127

und hier nach der Korrektur bei der 8. Box und Browser Refresh:

used_entries   488
free_entries   142
total_entries   630
namespace_count   15
percent_used   77.46032

[tostmann]

Danke, die Zahlen waren eindeutig: von deinen 136 freien Einträgen sind 126 eine Seite, die der Speicher sich dauerhaft für seine eigene Verwaltung reserviert und nie herausgibt. Real nutzbar waren also 10 — zu wenig für eine Preset-Slice. Der Speicher ist wirklich voll, auch wenn die Anzeige 78 Prozent sagt.

v0.8.43 ist raus. Damit wird das Preset, dessen Speichern fehlschlägt, nicht mehr an der Box gelöscht. Der Stick merkt sich einen fehlgeschlagenen Schreibvorgang und holt sich die Lücke beim nächsten Start vom Lautsprecher zurück, statt ihm eine unvollständige Liste zu schicken. Am Testgerät habe ich das an der echt vollen Partition nachgestellt: über vier Neustarts blieb das betroffene Preset jedes Mal auf der Box und war danach auch im Stick wieder da.

Ehrlich dazu: mehr Platz schafft das nicht. Solange der Speicher voll ist, wird das Speichern dieses einen Presets weiter fehlschlagen — nur der Verlust an der Box ist weg, und das ✕ sollte dir den 500er nicht mehr in Kombination mit einem verschwundenen Preset bescheren.

Update wie immer über SYSTEM → Online update. Wenn es wieder auftritt, gerne nochmal derselbe Dump plus die nvs/stats-Zahlen.

[fred_feuerstein]

hab die .43 gleich installiert.

Direkt nach erstem Reboot steht der eine Preset wie gestern auf dem Screenshot da mit dem "X" muss er dann weggeklickt werden. Auch mit der 500er Meldung, dann Browser Refresh und im Header der Preset Save Fail.

Vor "X" und Refresh:
used_entries   488
free_entries   142
total_entries   630
namespace_count   15
percent_used   77.46032

Nach "X" und Refresh:
used_entries   489
free_entries   141
total_entries   630
namespace_count   15
percent_used   77.61905

Code Auswählen Erweitern

{
  "name": "SixBack",
  "version": "0.8.43",
  "build": "2026-08-09 21:05:09",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 309,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -23,
    "channel": 5,
    "band": "2.4GHz",
    "mac": "1C:DB:D4:74:9F:44",
    "hostname": "sixback.local",
    "improv_active": false,
    "improv_window_s": 0,
    "captive_active": false,
    "captive_window_s": 0
  },
  "heap": {
    "free": 123584,
    "min_free": 87992,
    "total": 339128,
    "largest_block": 59380,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8363376,
    "total": 8388608
  },
  "chip": {
    "model": "ESP32-S3",
    "cores": 2,
    "revision": 2,
    "flash_size": 16777216
  },
  "cloud_replacement": {
    "port": 8000,
    "base_url": "http://192.168.123.173:8000"
  },
  "speakers_count": 9,
  "scan_in_progress": false,
  "groups_persist_ok": true,
  "preset_store": {
    "load_ok": true,
    "save_fails": 1,
    "speakers": 8,
    "save_heap_aborts": 0,
    "save_nvs_fails": 1
  },
  "inventory": {
    "save_fails": 0
  },
  "health": {
    "boot_count": 1,
    "crash_count": 0,
    "wifi_reboots": 0,
    "heap_reboots": 0,
    "wifi_disconnects": 0,
    "last_wifi_down_s": 0,
    "last_reset": "SW",
    "wdt_subscribed": true,
    "wifi_down_for_s": 0,
    "heap_low_for_s": 0,
    "heap_low_events": 0,
    "last_heap_low_s": 0,
    "last_ping_age_s": 9
  }
}
Dann nochmal Reboot als Test. Der eine Preset bei der Box steht wieder mit Push/X da, was erneut weggeklickt werden muss.
Also für mich kein Unterschied sichtbar.

[tostmann]

Was du beschreibst, ist der vorgesehene Zustand — der Gewinn von .43 liegt an der Box, nicht im Browser: das Preset wird dort nicht mehr gelöscht. Und der eine belegte Eintrag mehr in deinen Zahlen (488 → 489) ist genau der neue Schutzmarker, den .43 bei einem fehlgeschlagenen Speichern setzt. Der Mechanismus ist bei dir also nachweislich aktiv.

Das ✕ musst du ab jetzt nicht mehr klicken. Mit gesetztem Marker holt sich der Stick die Lücke nach jedem Neustart selbst von der Box zurück — angestoßen von deren erster Anfrage beim Stick, das dauert bis zu eine Minute. Direkt nach dem Reboot steht die Meldung also noch da; nach kurzem Warten und einem Browser-Reload sollte sie von allein verschwinden. Falls sie das bei dir nach ein paar Minuten nicht tut, wäre genau das eine wichtige Rückmeldung. Der "Preset Save Fail" im Header wird dagegen wiederkommen, und der 500er beim ✕ auch: beide sagen ehrlich, dass der zurückgeholte Stand nicht in den Flash passt — von deinen 141 freien Einträgen sind nach Abzug der Reserve 15 nutzbar, das Speichern einer Box braucht mehr.

Zum Platz selbst ist zu sagen: die Einstellungs-Partition ist fix 20 KB groß und per Online-Update nicht vergrößerbar, weil direkt dahinter die App-Partitionen liegen — umpartitionieren ginge nur per USB-Neuflash, und der löscht alle Einstellungen, also das Gegenteil von dem, was du willst. Der Hebel, der bleibt, ist, dass die Firmware pro Box mit weniger Einträgen auskommt.

[fred_feuerstein]

Das ✕ musst du ab jetzt nicht mehr klicken. Mit gesetztem Marker holt sich der Stick die Lücke nach jedem Neustart selbst von der Box zurück — angestoßen von deren erster Anfrage beim Stick, das dauert bis zu eine Minute. Direkt nach dem Reboot steht die Meldung also noch da; nach kurzem Warten und einem Browser-Reload sollte sie von allein verschwinden. Falls sie das bei dir nach ein paar Minuten nicht tut, wäre genau das eine wichtige Rückmeldung. Der "Preset Save Fail" im Header wird dagegen wiederkommen, und der 500er beim ✕ auch: beide sagen ehrlich, dass der zurückgeholte Stand nicht in den Flash passt — von deinen 141 freien Einträgen sind nach Abzug der Reserve 15 nutzbar, das Speichern einer Box braucht mehr.

Das "X" bei dem einen Preset verschwindet hier nicht automatisch nach einem Browser-Reload. Hab jetzt nach SixBack Reboot über 5 Minuten gewartet.
Der "Problem-Preset" auf der Box ist kein TuneIn, sondern ein Preset auf lokales NAS. Aber das dürfte ja keinen Unterschied machen, oder?

Zum Platz selbst ist zu sagen: die Einstellungs-Partition ist fix 20 KB groß und per Online-Update nicht vergrößerbar, weil direkt dahinter die App-Partitionen liegen — umpartitionieren ginge nur per USB-Neuflash, und der löscht alle Einstellungen, also das Gegenteil von dem, was du willst. Der Hebel, der bleibt, ist, dass die Firmware pro Box mit weniger Einträgen auskommt.

d.h. diese Einstellungs-Partition könnte man schon etwas vergrößern? Aktuell 20kb auf bspw. 40kb würde denke ich alle Probleme lösen, oder? Habe die Presets ja pro Box gespeichert, also wäre ein Neu-Flash nicht so ein riesen Problem. Sind ja auch fast überall die gleichen 6 Presets auf den Lautsprechern. Spotify ist auch fix wieder eingestellt.
Würde aber bedeuten, dass alle User einmal neu starten müssten oder?
Also eher unpraktikabel... ??
Dann doch so wie bisher. Wie gesagt, ich komme ja klar damit.

 

[betateilchen]

Zum Platz selbst ist zu sagen: die Einstellungs-Partition ist fix 20 KB groß und per Online-Update nicht vergrößerbar, weil direkt dahinter die App-Partitionen liegen — umpartitionieren ginge nur per USB-Neuflash,

Als Softwareentwickler sehe ich das so:

• Bisher gibt es ja keine definierte Maximalzahl von Boxen pro Stick.
  
  
• Wenn es technisch die Möglichkeit gäbe, die Partition zu vergrößern (und sei es per Neu-Flash) dann sollte man diese Möglichkeit m.E. auch nutzen. Dabei könnte man dann eine Partitionsgröße wählen, die eine bestimmte Anzahl Boxen zuverlässig verwalten kann (z.B. 12 Boxen) und diesen Maximalumfang dann in die Dokumentation übernehmen. Danach gäbe es dann hoffentlich keine Diskussion zum Thema "Boxen-Anzahl" mehr, man würde auf die festgeschriebene Zahl verweisen.
  
  
• Ja, es mag ein Breaking Change sein. Aber die aktuelle Situation halte ich grundsätzlich für weniger zumutbar, als einmal neu flashen zu müssen. Zumal wir uns ja versionmäßig immer noch im Bereich 0.xxx bewegen, da sollte man mit solchen Changes grundsätzlich rechnen.