BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

[tostmann]

Danke für die Zahlen — genau das brauchte ich.

Zu den nvs/stats: 79 % belegt / 132 freie Entries ist per se noch kein kritischer Füllstand. Der Save-Mechanismus hält beim Schreiben kurzzeitig den alten und den neuen Stand parallel im Flash (deshalb überlebt der aktive Stand einen fehlgeschlagenen Save) und braucht daher konstruktionsbedingt etwas Luft — entscheidend ist, ob der größte Einzel-Store beim Schreiben in die freien Entries passt. Dass deine Werte vor und nach dem Reboot identisch sind, zeigt zumindest: da wächst und leckt nichts.

Zum ,,einen" preset save fail nach dem Boot: die save-fail-Zähler zählen seit dem letzten Boot, sie werden nicht persistiert. Dein Muster heißt also: bei jedem Boot schlägt genau ein Save kurz nach dem Start fehl, danach läuft es über einen Tag sauber. Zu einer echten Platzgrenze passt das nicht — die würde auch später zuschlagen, und deine freien Entries sind ja stabil. Das ist ein Boot-Zeitfenster-Effekt; die Ursache kann ich noch nicht festnageln.

Was mir beim Durchsehen des Codes aufgefallen ist: die Firmware selbst stößt in deiner Konstellation (alle Boxen längst migriert) beim Boot keinen Preset-Save an — sämtliche Schreibpfade in den Preset-Store laufen über die Web-Oberfläche. Irgendetwas außerhalb des Sticks speichert also direkt nach dem Boot. Daher zwei Fragen:

• Ist bei dir typischerweise ein Browser-Tab mit der SixBack-Oberfläche offen, wenn der Stick rebootet?
• Greift FHEM (oder etwas anderes) automatisiert auf den Stick zu — auch nur lesend/pollend wäre interessant zu wissen?

Falls ja, würde das zeitlich auch zum ,,Presets auf Push"-Phänomen direkt nach dem Reboot passen — ob die beiden Dinge wirklich zusammenhängen, ist aber offen.

Die 3 inventory save fails von heute früh sind für mich das interessantere Signal, weil sie im laufenden Betrieb passiert sind. Weißt du noch, ob da zeitgleich etwas mit den Boxen los war (eine offline/online gegangen, Netzwerk-Ereignis)? Kamen die drei vermutlich auf einen Schlag oder verteilt?

Falls du seriell mitlesen kannst: die Zeilen, die mit "[nvs-save]" bzw. "[nvs-cleanup]" beginnen, aus der ersten Minute nach dem Boot würden die Fehlerklasse eindeutig machen — da steht konkret drin, ob der Write gar nicht erst gestartet wurde (inkl. ,,brauche ~X Entries, frei Y" zum genauen Zeitpunkt) oder ob er beim Schreiben bzw. Verifizieren scheiterte, und nebenbei liefern sie die realen Größen deiner Stores. Das wäre der letzte fehlende Baustein.

Zur Einordnung: Handlungsdruck sehe ich keinen — ein fehlgeschlagener Save verliert keine Presets (der aktive Stand bleibt unangetastet, der nächste erfolgreiche Save heilt), es werden dabei nur die im letzten Post beschriebenen regenerierbaren Caches aufgeräumt. Deine Presets sind ja nachweislich stabil.

[fred_feuerstein]

Ist bei dir typischerweise ein Browser-Tab mit der SixBack-Oberfläche offen, wenn der Stick rebootet?

Ja, ein Browser-Tab ist offen während eines gewollten Reboots (entweder nach Firmware Update oder klick auf Reboot)

Greift FHEM (oder etwas anderes) automatisiert auf den Stick zu — auch nur lesend/pollend wäre interessant zu wissen?

es greift kein anderes System automatisiert auf SixBack zu. Also weder fhem noch was anderes.

Der eine Presets Save Fail kommt nicht direkt nach Reboot. Wenn nach Reboot Sixback wieder da ist habe ich ja das Anzeige-Problem bei ein oder zwei Lautsprechern mit "Push"... Wenn ich den Browser-Refresh der Seite anstosse um das zu lösen, dann kommt meist der Save Fail bei den Presets aber die Anzeige passt wieder.
Aber es kommt dann auch kein weiterer Save-Fail mehr hinzu.

Die 3 inventory save fails von heute früh sind für mich das interessantere Signal, weil sie im laufenden Betrieb passiert sind. Weißt du noch, ob da zeitgleich etwas mit den Boxen los war (eine offline/online gegangen, Netzwerk-Ereignis)? Kamen die drei vermutlich auf einen Schlag oder verteilt?

Nein, da kann ich aktuell noch nichts eingrenzen. Aber die 3 waren auf einen Schlag da.

Aktuell keine weiteren Inventory Save Fails.

SixBack seit 13 Stunden online und ⚠ store: 2 preset save fails.

Eben war es nur 1 Save Fails als ich SixBack aufgerufen habe. Dann wieder Push-Meldungen bei 3 Lautsprechern. Browser Refresh, Anzeige passt wieder, aber es stehen nun 2 preset save fails.

Code Auswählen Erweitern

{
  "used_entries": 504,
  "free_entries": 126,
  "total_entries": 630,
  "namespace_count": 15,
  "percent_used": 80
}

Code Auswählen Erweitern

{
  "name": "SixBack",
  "version": "0.8.38",
  "build": "2026-07-30 21:47:14",
  "license": "PolyForm-Noncommercial-1.0.0",
  "copyright": "Copyright (c) 2026 Dirk Tostmann",
  "uptime_s": 50295,
  "wifi": {
    "connected": true,
    "ssid": "hannebambel HOME",
    "ip": "192.168.123.173",
    "rssi": -22,
    "channel": 11,
    "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": 111244,
    "min_free": 68736,
    "total": 339176,
    "largest_block": 50164,
    "outbound_rejects": 0
  },
  "psram": {
    "free": 8358916,
    "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": 2,
    "speakers": 9,
    "save_heap_aborts": 0,
    "save_nvs_fails": 2
  },
  "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": "POWERON",
    "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": 191
  }
}
wie gesagt, das WebInterface ist insgesamt träge geworden, dauert einfach eine ganze Weile bis die Lautsprecher und die Presets gefüllt werden. Und ich denke, wenn es etwas zu lange dauert bleiben ein paar Lautsprecher mit den Push-Meldungen stehen. Ist aber wie schon verifiziert nur ein Anzeige-Problem.

[tostmann]

Deine Beobachtung aus dem letzten Post — der Save-Fail kommt beim Browser-Refresh, nicht beim Boot — war der entscheidende Hinweis. Damit ließ sich der Pfad im Code eingrenzen, und ich bin fündig geworden. Es sind zwei getrennte Dinge, die beide beim (Neu-)Laden der Seite passieren.

Zur Push-Anzeige: beim Seitenaufbau fragt der Stick für jede Box parallel deren aktuelle Hardware-Presets ab. Schlägt so eine Abfrage fehl (Timeout, Box antwortet gerade nicht — bei 9 Boxen parallel kann das passieren), zeigt die Oberfläche das fälschlich als auf der Box ist nichts an, mit Push-Knopf — statt zu sagen Box gerade nicht erreichbar. Beim nächsten erfolgreichen Abruf (Reload, oder der Kontrollabruf nach einem Push) stimmt die Anzeige wieder. Das erklärt auch betateilchens Beobachtungen (Geduld heilt, Push-Klick heilt) und warum es wechselnde Boxen trifft. Reines Anzeigeproblem, wie ihr beide schon vermutet habt — aber jetzt mit benennbarer Ursache.

Zum Save-Fail: die Weboberfläche macht bei jedem frischen Seitenaufbau einen Abgleich — hat der Stick für eine Box noch keine Presets gespeichert, die Box selbst aber welche, importiert er sie automatisch (der Erstinstallations-Komfort). Dieser Import schreibt den kompletten Preset-Speicher neu in den Flash. Und bei dir gab es genau so eine Box: deine Statusabzüge zeigten bisher 9 Boxen im Inventar, aber nur 8 mit gespeicherten Presets — im heutigen Abzug sind es erstmals 9. Jeder frische Seitenaufbau hat diesen Import samt Schreibversuch ausgelöst, und der Schreibversuch scheitert bei dir. Eine Frage dazu: gibt es bei dir eine Box, für die du nie Presets über SixBack verwaltet hast (die aber selbst welche gespeichert hat)? Das würde das Bild abrunden.

Damit klärt sich auch dein offener Browser-Tab: nach einem Stick-Reboot lädt die offene Seite sich selbst neu (damit man nach einem Update nicht von Hand nachladen muss) — jeder Reboot mit offenem Tab ist also automatisch so ein frischer Seitenaufbau. Deshalb sah es nach einem Boot-Effekt aus, obwohl es keiner ist.

Offen bleibt, WARUM der Schreibversuch bei dir scheitert (Platz-Ablehnung vorab, Fehler beim Schreiben, oder Fehler beim Gegenlesen) — das steht nur in den seriellen Meldungen. Die gute Nachricht aus dem Befund: du musst dafür keinen Boot mehr abpassen. Serielle Konsole öffnen, in der Weboberfläche F5 drücken — wenn der Fail kommt, stehen die Zeilen sofort da:

Code Auswählen Erweitern

[nvs-save] ...
[nvs-cleanup] ...
Wenn du das bei Gelegenheit einmal machen könntest, wäre die Fehlerklasse eindeutig. Auch dein zweiter Fail von gestern (der bei 13 h Laufzeit) ist mit dem Import allein noch nicht restlos erklärt — dieselben Zeilen würden das gleich mitklären.

Zur Einordnung wie gehabt: verloren geht dabei nichts, der aktive Bestand bleibt bei einem fehlgeschlagenen Save unangetastet. Beide Baustellen — die irreführende Push-Anzeige und der Import-Schreibversuch bei jedem Seitenaufbau — liegen auf meiner Seite; ich entschärfe sie in einer der nächsten Versionen.

[tostmann]

v0.8.39 ist online. Die Partitionen sind unverändert, das Update geht also einfach über ⚙ SYSTEM in der Weboberfläche (Check for update → Install) oder frisch über sixback.io; die Dateien hängen wie immer auch am GitHub-Release.

Der Release setzt um, was sich aus den letzten Posts hier ergeben hat — freds Beobachtung, dass der save fail am Browser-Refresh hängt und nicht am Boot, war der entscheidende Hinweis. Drei Änderungen:

1. Eine Box, die auf die Preset-Abfrage nicht rechtzeitig antwortet, wird nicht mehr als ,,leer" angezeigt. Genau daraus entstanden die ,,Presets stehen auf Push"-Meldungen bei wechselnden Boxen: ein fehlgeschlagener Abruf lief durch denselben Pfad wie eine echte leere Antwort, und die Karte zeigte ,,on speaker: (empty)" samt Push-Knopf. Jetzt gilt ein fehlgeschlagener Abruf als unbekannt — der letzte bekannte Stand bleibt stehen, ansonsten steht am Slot ,,not reachable — retrying", es gibt dafür keinen Push-Knopf, und es wird automatisch nachgelesen. Das erklärt auch, warum bei betateilchen Geduld oder ein Klick auf Push das Problem ,,heilte": beides führte schlicht zu einem neuen, diesmal erfolgreichen Abruf.

2. Der automatische Preset-Import von einer Box meldet jetzt ehrlich, wenn das Speichern in den Flash gescheitert ist. Bisher meldete er Erfolg, die Presets lagen dann aber nur im RAM und waren beim nächsten Neustart weg, ohne dass irgendwo etwas davon zu sehen war. Jetzt kommt eine klare Meldung in der Oberfläche, zusätzlich zum bekannten ⚠-store-Hinweis im Kopf.

3. Ein gescheiterter Import wiederholt sich nicht mehr bei jedem Seitenaufbau. Jeder dieser Versuche schrieb den kompletten Preset-Bestand neu und räumte im Fehlerfall regenerierbare Caches weg — bei einem Gerät an der Speichergrenze passierte das bei jedem Reload aufs Neue. Jetzt pausiert der automatische Import für die betroffene Box, bis irgendein Speichern wieder durchläuft oder der Stick neu startet.

Zur Einordnung, damit keine falschen Erwartungen entstehen: die Warum-Frage — weshalb der Schreibversuch bei dir, fred, überhaupt scheitert — ist damit noch nicht beantwortet. Du wirst nach einem Reboot beim ersten Seitenaufbau voraussichtlich weiterhin einen save fail sehen, jetzt aber mit klarer Meldung und ohne stilles Wiederholen. Meine Fragen aus dem letzten Post bleiben deshalb aktuell, besonders die, ob es bei dir eine Box gibt, deren Presets du nie über SixBack verwaltet hast.

Ein Hinweis zum seriellen Mitlesen, weil sich das mit .39 leicht ändert: da der Import nach einem Fehlschlag pausiert, löst F5 den Schreibversuch nicht mehr jedes Mal aus. Zwei einfache Wege bleiben — den ersten Seitenaufbau nach einem Reboot mit offener serieller Konsole erwischen, oder einfach irgendein Preset einmal neu speichern; auch das schreibt den kompletten Bestand und läuft in denselben Fehler, die Zeilen erscheinen sofort:

Code Auswählen Erweitern

[nvs-save] ...
[nvs-cleanup] ...
Noch zur Verifikation: die Fehlerpfade lassen sich im Feld schlecht nachstellen, deshalb wurde mit einem Testbuild geprüft, der den Schreibfehler künstlich erzwingt — gemeldeter Fehlschlag, unterdrückte Wiederholung und automatische Wieder-Freigabe nach einem erfolgreichen Speichern sind auf Hardware bestätigt.

[fred_feuerstein]

Erstmal Danke für Deine super schnellen Reaktionen... (hast wohl auch nicht gerne ToDos auf deiner internen Liste )

Eine Frage dazu: gibt es bei dir eine Box, für die du nie Presets über SixBack verwaltet hast (die aber selbst welche gespeichert hat)? Das würde das Bild abrunden.

Also bei mir werden 8 Lautsprecher über SixBack verwaltet. 1 Lautsprecher (bzw. ist es ein Soundtouch Wireles Link) wird über ST Reborn gesteuert. Dieses Device ist in SixBack als HIDE markiert und ausgeblendet. Mehr kann ich hier ja nicht machen, löschen bringt auch nichts, weil ein Reboot ihn automatisch wieder findet.
Dazu bräuchte es eine White- oder Blacklist mit IPs der gewünschten Lautsprecher.

Das mit dem Log werde ich versuchen. Kann den Stick morgen tagsüber mal an den PC hängen und ausprobieren welche Meldungen kommen.

hab eben auf die .39 upgedated:
Nach dem ersten Reboot der Seitenrefresh sah eigentlich gut aus. Aber unten rechts kam als er fertig war kurz eine Meldung, Presets could not be write in the flash ... und dass sie beim nächsten Reboot verloren wären .... oder so ähnlich. Die Meldung war zu schnell weg.
Im Header steht also wieder 1 Preset save fail.
Anzeige sieht aber komplett gut aus.

OK. Also ich werde das morgen mit dem Log mal testen und schauen ob man was sieht.

[tostmann]

Danke fürs schnelle Update und die Rückmeldung. Dass die Anzeige jetzt komplett gut aussieht, ist genau das, was der erste der drei Fixes bewirken sollte — der Push-Phantom-Teil ist damit vom Tisch.

Die Meldung, die zu schnell weg war

Da hast du gleich zwei Fehler auf einmal gefunden. Erstens verschwand jede Meldung nach vier Sekunden, egal was drinstand — auch eine, die sagt, dass die Presets nur im RAM stehen und beim nächsten Neustart weg sind. Zweitens war ausgerechnet diese Meldung im Code gar nicht als Fehler markiert, sie wurde also grün wie eine Erfolgsmeldung angezeigt. Beim Nachsehen kamen noch 19 weitere Fehlermeldungen dazu, die aus demselben Grund grün und flüchtig waren: Push failed, Play failed, Import failed, Set/Swap/Rename und die Ablehnungen beim Drag-and-Drop.

Ab dem nächsten Update bleiben rote Fehlermeldungen stehen, bis man sie wegklickt — Klick auf die Meldung selbst oder auf das ×. Grüne Erfolgsmeldungen verschwinden weiter nach vier Sekunden. Falls das im Alltag stört, gibt es dann im System-Bereich einen Schalter "Keep error messages on screen", der es wieder auf das alte Verhalten zurückstellt. Der Schalter gilt für den Browser, in dem du ihn umlegst, und wird nicht auf dem Stick gespeichert — auf einem Gerät, dem der Flash-Platz ausgeht, hat eine reine Anzeige-Einstellung dort nichts verloren.

Zum versteckten Wireless Link

Der ist nach allem, was ich im Code sehe, nicht der Auslöser. Versteckte Geräte werden gar nicht erst geladen, und damit läuft für sie auch kein automatischer Preset-Import. Der Import, der bei dir den Schreibfehler auslöst, gehört also zu einer der acht Boxen, die du tatsächlich über SixBack verwaltest.

Eine Rückfrage dazu, damit ich das nicht falsch annehme: klappst du die Zeile "N hidden speaker(s) — click to show" unter der Geräteliste manchmal auf? Solange die zugeklappt bleibt, gilt das oben Gesagte. Im aufgeklappten Zustand wird die versteckte Box mitgeladen, und dann kann sie sehr wohl mitspielen.

Warum es genau ein Fehler pro Neustart ist

Das deckt sich mit deiner Beobachtung, dass danach kein weiterer dazukommt. Wenn ein Import den Flash nicht schreiben kann, merkt sich SixBack dieses Gerät und versucht es nicht wieder — allerdings nur bis zum nächsten Neustart, denn diese Merkliste steht im RAM. Nach jedem Reboot gibt es also genau einen Versuch, der scheitert, danach ist Ruhe. Deshalb springt der Zähler im Header auf 1 und bleibt dort.

Was damit ausdrücklich nicht geklärt ist: warum der Schreibvorgang überhaupt scheitert. Dein Dump zeigt 504 von 630 belegten Einträgen, und das ist die Kapazitätsgrenze, an der wir das im Labor ebenfalls reproduzieren konnten. Was seit v0.8.34 gilt, ist, dass an dieser Kante ein sauberer Fehler entsteht statt eines Datenverlusts — größer wird die Kapazität dadurch nicht.

Zum Log morgen

Serielle Konsole mit 115200 Baud, und interessant sind genau zwei Zeilenarten:

Code Auswählen Erweitern

[import] <Geraet>: N Presets im RAM, aber NVS-Persist FEHLGESCHLAGEN
[nvs-save] FAIL ...

Die erste sagt, welche Box es ist. Die zweite sagt, woran es liegt: je nachdem steht dort REFUSED (der Platz reicht schon vor dem Schreiben nicht), FAIL putBytes (das Schreiben selbst bricht ab), FAIL readback oder FAIL gen-commit. Das ist der Unterschied zwischen "Partition voll" und "es stimmt etwas anderes nicht", und genau den kann ich aus der Ferne nicht raten — deshalb ist dein Log der nächste sinnvolle Schritt und nicht noch eine Vermutung von mir.

Ausgelöst wird es beim ersten Laden der Seite nach einem Neustart, oder wenn du irgendein Preset speicherst. Ein bloßer F5-Refresh reicht seit v0.8.39 nicht mehr, weil der gescheiterte Import ja gesperrt wird.

Zur White-/Blacklist

Der Punkt ist berechtigt: HIDE ist heute reine Anzeige, das Gerät bleibt im Inventar und wird beim Reboot wiedergefunden. Ich würde damit trotzdem warten, bis dein Log da ist. Wenn der Schreibfehler an einer der acht verwalteten Boxen hängt, löst eine Ignore-Liste ihn nämlich nicht, und ich möchte ungern die falsche Baustelle aufmachen.

[fred_feuerstein]

vorab. den Hidden-Speaker klappe ich nicht auf. Es ist also nur die eine Zeile zu sehen: 1 hidden speaker(s) — click to show


Ansonsten. Habe nach dem Reboot (angeschlossen am PC) mal geschaut, was für Log-Einträge kommen.

Code Auswählen Erweitern

[11:03:45][nvs-save] FAIL putBytes ns=sixback-pre key=presets~ json_len=9603 blob=4846 wrote=0 (hs)
[11:03:45][nvs-cleanup] sixback-pre/presets save fail — pass1 purging caches + retry
...
[11:03:45][nvs-save] FAIL putBytes ns=sixback-pre key=presets~ json_len=9603 blob=4846 wrote=0 (hs)
[11:03:45][nvs-cleanup] sixback-pre/presets pass1-fail — pass2 wider purge
...
[11:03:46][nvs-save] FAIL putBytes ns=sixback-pre key=presets~ json_len=9603 blob=4846 wrote=0 (hs)
[11:03:46][nvs-cleanup] sixback-pre/presets -> STILL-FAIL — NVS partition genuinely full (aktiver Stand bleibt konsistent)
[11:03:46][preset] saveToNVS FAILED (nvs write, #1)
[11:03:46][import] B0D5CC3D160E: 6 Presets im RAM, aber NVS-Persist FEHLGESCHLAGEN
[11:03:48][heartbeat] up=30s  RSSI=-76  free-heap=117276  PSRAM-free=8352284
...

Also es sieht so aus. Habe jetzt "unzählige" Neustarts gemacht. Neben dem reinen Anzeigeproblem (teilweise mit Push-Meldung, teilweise sogar mal wieder "leere Presets"), was verschiene Lautsprecher betreffen kann, was aber mit Browser-Refresh behoben werden kann, kommt der Save-Fail eigentlich immer bei der gleichen Box.

Die Box funktioniert aber ohne Probleme, hat ihre Speicher etc. Und im Webif sieht genau diese Box auch dementsprechend aus.

Es ist halt beim Reboot im Webif die besagte "grüne" Meldung zu sehen, die eigentlich rot sein sollte. Wie vorher schon beschrieben.

Ansonsten läuft alles.

Vielleicht sollte ich diese Box nochmal komplett zurücksetzen und neu starten?! Das werde ich testen.

[fred_feuerstein]

fange ein neues Posting an...

Habe diese "Problembox" nun mal zurückgesetzt und neu eingerichtet, WLAN, usw. Nun ist sie in SixBack wieder zu sehen. Es steht aber noch dort, dass sie bereits migriert ist.
Egal. Habe auch Resync-Sources durchgeführt.

alle 6 Presets sind leer bei der Box. Auch nach Reboot vom SixBack.

Aber ich kann keine Presets speichern. Wenn ich versuchen einen Radio Sender auf einen Preset zu ziehen, kommt wieder die "grüne" Meldung unten rechts.
Und im Log tauchen diese Meldungen auf:

Code Auswählen Erweitern

[11:48:14][nvs-save] FAIL putBytes ns=sixback-pre key=presets~ json_len=8305 blob=3918 wrote=0 (hs)
[11:48:14][nvs-cleanup] sixback-pre/presets save fail — pass1 purging caches + retry
[11:48:14][134575][E][Preferences.cpp:539] getBytesLength(): nvs_get_blob len fail: presets~ NOT_FOUND
[11:48:14][134584][E][Preferences.cpp:93] remove(): nvs_erase_key fail: presets~ NOT_FOUND
[11:48:14][134891][E][Preferences.cpp:291] putBytes(): nvs_set_blob fail: presets~ NOT_ENOUGH_SPACE
[11:48:14][nvs-save] FAIL putBytes ns=sixback-pre key=presets~ json_len=8305 blob=3918 wrote=0 (hs)
[11:48:14][nvs-cleanup] sixback-pre/presets pass1-fail — pass2 wider purge
[11:48:15][135021][E][Preferences.cpp:539] getBytesLength(): nvs_get_blob len fail: presets~ NOT_FOUND
[11:48:15][135029][E][Preferences.cpp:93] remove(): nvs_erase_key fail: presets~ NOT_FOUND
[11:48:15][135245][E][Preferences.cpp:291] putBytes(): nvs_set_blob fail: presets~ NOT_ENOUGH_SPACE
[11:48:15][nvs-save] FAIL putBytes ns=sixback-pre key=presets~ json_len=8305 blob=3918 wrote=0 (hs)
[11:48:15][nvs-cleanup] sixback-pre/presets -> STILL-FAIL — NVS partition genuinely full (aktiver Stand bleibt konsistent)
[11:48:15][preset] saveToNVS FAILED (nvs write, #1)
Demnach kann ich diese Box nicht mehr einrichten. Selbst der PlayBack eines Radio-Senders als Preview auf dieser Box scheitert mit einem "Speaker-Preview Error HTTP 502".

werde die Box nun mal versuchen mit dem 2. SixBack (den ich bisher nicht brauchte) einzurichten.


edit:
Box ist nun mit dem 2. SixBack wieder eingerichtet. Und im Anschluss habe ich sie wieder auf den 1. SixBack migriert.

D.h. ich lebe jetzt erstmal mit den Save-Fails und beobachte weiter was mir noch so auffällt.

Möchte echt vermeiden einen 2. SixBack zu benötigen.

[fred_feuerstein]

sorry, noch ein Post...

Jetzt sind ja wieder 8 Lautsprecher (alle verwaltet vom SixBack) zu sehen und die Wireless Link (9. Lautsprecher steht auf HIDE).
Du darfst diesen Dateianhang nicht ansehen.

komischerweise habe ich seit dem nun keine "Push-Meldungen" mehr bei irgendeinem der 8 Lautsprecher gesehen... bisher.

Aber trotzdem wieder:
⚠ store: 1 preset save fail · 7 inventory save fails


Eine Frage noch zu den eigenen Stream-Urls. Diese kann man ja Exportierung und importieren.
Hatte hier bisher immer 8 Streams abgelegt. Wo sind die auf dem SixBack gespeichert? In einem kritischen Speicherbereich?
Hab die URLS nun dort erstmal gelöscht:
Du darfst diesen Dateianhang nicht ansehen.

Wenn die eher unkritisch sind importiere ich sie auch wieder. Aktuell werden sie eigentlich aber nicht benötigt. Mache momentan alles über tunein (die haben einfach die besten Infos als Anzeige auf den Lautsprecher-Displays, u.a. Titel-Infos, usw. das gibts nur bei TuneIn)

[tostmann]

Danke für die Logs und die Screenshots — damit ist das Bild jetzt vollständig, und deine Experimente haben die Diagnose sogar noch schärfer gemacht. Der Reihe nach.

Was dein Log endgültig beweist

Code Auswählen Erweitern

[E][Preferences.cpp:291] putBytes(): nvs_set_blob fail: presets~ NOT_ENOUGH_SPACE
Diese Zeile ist der rohe Fehlercode aus dem Speichersystem selbst, und er beantwortet die Warum-Frage abschließend: der reservierte Flash-Bereich (NVS) hat schlicht nicht mehr genug Platz. Kein Defekt, keine Größenbeschränkung eines einzelnen Datensatzes — der Bereich ist voll. Dein gescheiterter Versuch, einen Sender per Drag-and-Drop auf ein Preset zu ziehen, bestätigt leider auch die unangenehme Konsequenz aus meinem Befund: in diesem Zustand kann der Stick gar keine Preset-Änderung dauerhaft speichern, an keiner Box. Die NOT_FOUND-Zeilen dazwischen sind übrigens harmlos — da prüft die Schutzmechanik einen Reserve-Ablageplatz, der noch nicht existiert; das ist der Normalfall, kein Fehler.

Auch die 7 inventory save fails passen exakt ins Bild: die Geräteliste schreibt in denselben Bereich, dein Neu-Einrichten und Zurück-Migrieren hat mehrere Schreibversuche ausgelöst, und die sind an derselben Grenze gescheitert. Gleiche Ursache, kein zweites Problem.

Zur Box selbst: schade um die sechs Presets — die existierten dauerhaft nur auf der Box, weil der Stick sie ja nie sichern konnte; genau davor wollte ich dich noch warnen, da warst du schneller. Gut, dass du sie über den zweiten Stick wiederherstellen konntest. Den Preview-Fehler (HTTP 502) in diesem Fenster kann ich von hier aus nicht sicher zuordnen — falls er nach dem Neu-Einrichten wieder auftaucht, sag Bescheid.

Deine Stream-Frage — und warum das Löschen ein Volltreffer gewesen sein könnte

Ja: die eigenen Stream-URLs liegen im selben reservierten Bereich, als ein gemeinsamer Datensatz mit den vollen URLs. Acht Einträge mit langen URLs sind dort ein spürbarer Posten. Dein Löschen war also genau der richtige Gedanke — es gibt echten Platz frei, und es ist gut möglich, dass das deine Lage bereits entspannt hat.

Deshalb eine konkrete Bitte: zieh einfach nochmal einen Sender auf ein Preset. Wenn das jetzt ohne Fehlermeldung durchgeht, ist der Knoten geplatzt — und beim nächsten Seitenaufbau übernimmt der Stick dann auch die Presets der neu eingerichteten Box wieder automatisch (der Automatik-Import pausiert nach einem Fehlschlag absichtlich, bis irgendein Speichern wieder klappt — ein erfolgreiches manuelles Speichern löst diese Pause).

Zwei ehrliche Anmerkungen dazu: Ob das Löschen der Streams selbst dauerhaft gespeichert wurde, zeigt erst ein Neustart des Sticks — bleiben die Streams danach weg, ist es gesichert. Die Chancen stehen gut, weil dieser Schreibvorgang winzig ist, aber versprechen kann ich es nicht. Und mit dem Wieder-Importieren würde ich warten: jeder Import belegt den Platz wieder, und du stehst mit neun Boxen ohnehin dicht an der Grenze. Solange TuneIn dich abdeckt, lass sie draußen, bis ich die Ablage umgestellt habe.

Wie es weitergeht

An der Einordnung ändert sich nichts: das ist eine Grenze der jetzigen Ablage (ein gemeinsamer Datensatz für alle Boxen), nicht deiner Hardware. Der saubere Weg ist, die Presets pro Box einzeln abzulegen — dann muss bei einer Änderung nicht mehr alles auf einmal passen, und eine einzelne Box kann den Rest nicht blockieren. Das schaue ich mir jetzt an und melde mich, wenn es dazu etwas Belastbares gibt. Einen zweiten SixBack brauchst du dafür ausdrücklich nicht — dein Fall hat die Diagnose komplett gemacht, danke für die Geduld und die gründlichen Rückmeldungen.

[fred_feuerstein]

ein weiteres Speichern eines Presets geht nicht. Gerade probiert. Speicher scheint voll zu sein.

Ok. Aber momentan haben ja alle ihre passenden Presets. Also erstmal OK soweit.