BoseFix32 — lokaler SoundTouch-Cloud-Ersatz auf einem ESP32

Begonnen von tostmann, 21 Mai 2026, 00:26:36

Vorheriges Thema - Nächstes Thema

tostmann

SixBack v0.8.0 — DLNA-Browse landet

Hi Fred,

gerade rausgegangen: in der WebUI gibt es jetzt einen eigenen DLNA-Tab. Speaker auswählen, dann den DLNA-Server (alles was der Bose über /listMediaServers meldet — MiniDLNA, Twonky, Fritz!Mediaserver...), durch die Ordner klicken und Track oder Container per Drag&Drop auf einen Preset-Slot ziehen. Der ESP schaltet im Hintergrund die Quelle um, hält den Slot-Knopf "gedrückt" und liest das OPAQUE-ContentItem zurück in den Store.

Webflasher wie immer:  https://sixback.io/  (manifest.json v0.8.0, gebaut für S3 + C3 + C6 // ESP32-classic ist leider zu klein)

Bonus oben drauf: Migrate und Reboot haben jetzt einen Schritt-für-Schritt-Fortschrittsdialog statt nur einem Toast, mit Status-Polling und sauberem Timeout-Hinweis falls der Bose mal nicht zurückkommt.

Wichtige Einschränkung: das hilft Speakern die den DLNA-Server bereits kennen. Für Boxen die "STORED_MUSIC" noch nie registriert hatten, ist das Bootstrap-Problem noch nicht gelöst — das ist Phase (a) und steht für eine der nächsten Versionen an. Wenn du eine Box hast wo DLNA grundsätzlich schon spielt, probier es bitte aus und schreib was rauskommt — besonders ob das Drag-on-Slot bei deinem Setup (Twonky, Synology, NAS, was-auch-immer) durchgeht.

Issues + Code: https://github.com/tostmann/SixBack/releases/tag/v0.8.0

fred_feuerstein

#16
Danke für die Version. Hatte OTA Update gestartet, aber es lief nur bis zu ca. 30 Prozent. Dann brach es ab. Ein Seitenreload hat den ESP32 S3 dann nicht mehr erreicht. Reboot etc. hat nichts geändert.
Flash über sixback.io => hier erst das "Update" probiert. Das lief durch, aber der ESP32 war danach immer noch nicht erreichbar. Manuelles Update einzelner Bereiche habe ich nicht versucht. Dann also die Fresh-Installation incl. Erase. Das hat funktioniert. Musste nur Spotify neu connecten. Der Rest, also meine 9 Bose Devices waren beim ersten Start direkt da und ich habe nur die Auto Migration gleich abgebrochen. Das möchte ich aktuell ja noch nicht ;)

Was das für ein Problem war kann ich nicht sagen. Hatte bei den vorherigen OTA Updates problemlos funktioniert.

Wegen DLNA Problem habe ich im Github ein ISSUE angelegt.

Und jetzt hab ich noch ein passendes Gehäuse für den sixback esp32 s3:
Gruß, Fred

NEU: FHEM auf Raspberry PI 5, OS: Bookworm, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art

tostmann

Kurzes Update: SixBack v0.8.1 ist raus.

Zwei gemeldete Punkte sind behoben:
  • Bootloop auf dem ESP32-C3 — läuft jetzt sauber.
  • DLNA-Browser zeigt jetzt direkt eure Mediaserver an, ohne Umweg über eine externe Adresse.
Außerdem lassen sich C3 und C6 wieder per OTA aktualisieren. Einmalig müssen die beiden über https://sixback.io/ neu geflasht werden (Partitions-Umstellung), danach kommen Updates wieder over-the-air.

Die "kleinen Dinger" sind hart an ihrem Limit ...

Rückmeldungen wie immer gern!

fred_feuerstein

Update von 0.8.0 auf 0.8.1 auf dem ESP32 S3 schlägt bei mir fehl.

- Check for Update
- es wird Update available 0.8.1 angezeigt
- Install Update => mit Bestätigungsfenster
- dann kommt rote Meldung rechts unten, siehe Screenshot:
Gruß, Fred

NEU: FHEM auf Raspberry PI 5, OS: Bookworm, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art

tostmann

Ursache gefunden, @fred_feuerstein. Der S3 hat eine große LittleFS-Partition, daher lädt das Online-Update beim S3 ein rund 10 MB großes Web-UI-Image über HTTPS — bei C3/C6 sind es nur ~256 KB, deshalb tritt das dort nicht auf.

Der OTA-Client in 0.8.0 bricht ab, wenn beim Download länger als 5 Sekunden keine Daten ankommen. Stockt dein WLAN während des großen S3-Downloads also kurz, hält der Client das fälschlich für das Stream-Ende und bricht zur Sicherheit ab (kein Brick — das Gerät bleibt heil auf 0.8.0), und genau das erzeugt die rote Fehlermeldung. Auf einer stabilen Verbindung läuft derselbe Download komplett durch (hier reproduziert: volle ~10 MB plus Firmware in ca. 60 Sekunden).

In 0.8.1 ist das behoben (Idle-Timeout von 5 auf 30 Sekunden erhöht plus zusätzliche Content-Length-Prüfung) — nur kommt dein 0.8.0-Client per Online-Update evtl. nicht zuverlässig dorthin (Henne-Ei-Problem).

Verlässlicher Weg auf die aktuelle Version 0.8.2 — ohne USB, ohne Verlust deiner Einstellungen:

Lade die beiden Dateien herunter (jetzt auch direkt in den ,,Supported targets"-Kacheln auf sixback.io verlinkt):
Dann in der Geräte-WebUI unter Firmware update → Manual upload: das App-Image (firmware.bin) über Flash app, das Web-UI-Image (littlefs.bin) über Flash web UI. Das schiebt die Images direkt aus deinem Browser über das lokale Netz ins Gerät — kein stockanfälliger HTTPS-Pull — und NVS/Presets bleiben unangetastet.

Alternativ kannst du das Online-Update einfach nochmal probieren; auf einer ruhigen Leitung läuft es meist sofort durch. Mit 0.8.2 ist das Online-Update dann dauerhaft robust.

fred_feuerstein

#20
Ich werde die manuellen Updates wie von dir beschrieben probieren.

Aber das Problem vom Update war in dem Fall nicht eine schlechte wifi oder Internet Verbindung, denn die rote Fehlermeldung kommt sofort nach Klick auf Update.
er versucht es aktuell gar nicht erst.

(Mein esp32 S3 steht neben der fritzbox, hat also ausreichend wifi, würde ich vermuten)

Gebe dann Rückmeldung.

=> habe es nochmal OTA versucht => gleicher Fehler beim Versuch auf 0.8.3 => Der Fehler kommt direkt nach Klick auf Update.
=> dann Versuch manuell mit den von Dir verlinkten Dateien => App Firmware konnte aktualisiert werden. => Web UI (...littlefs.bin) kommt direkt nach Klick auf Flash web UI wieder ein roter Fehler rechts unten. Siehe angehängter Screen.
kann es sein, dass bei der 0.8.0 die Partition zu klein erstellt wurde, statt 10MB nur 1MB? So würde ich die Fehlermeldung interpretieren.

Denke, ich werde wohl nochmal von vorne über USB anfangen müssen mit Erase...

Edit: bin nun auf 0.8.3, nach USB Update mit Erase.

- DLNA Browser funktioniert :)
- Übersicht der Lautsprecher super mit den ausklappbaren Presets :)


und wie immer noch eine Frage: Auf der WebUI aber auch unter sixback.io gibt es keinen Link zur sixback github Seite, oder? Fände ich ganz gut, dann könnte man gerade aktuell direkt mal zu Github wechseln und nachschauen was es Neues gibt. Vielleicht auch als Link unten in der Fusszeile?! (nur als Anregung ;) )
Gruß, Fred

NEU: FHEM auf Raspberry PI 5, OS: Bookworm, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art

tostmann

Hi Fred,

danke für den Screenshot — der zeigt's exakt, und dein Verdacht war fast richtig, nur an der falschen Stelle:

Die Meldung ,,file is too big (9.88 MB, max 1.00 MB)" kam von einem Größen-Limit in der WebUI selbst, nicht von der Flash-Partition. Der manuelle ,,Flash web UI"-Upload hatte noch ein altes 1-MB-Limit drin (Relikt aus der Zeit, als das Web-UI-Image winzig war). Das S3-Web-UI-Image ist inzwischen ~9,9 MB groß — und genau das hat der Check sofort abgelehnt, bevor überhaupt etwas geschrieben wurde. Die LittleFS-Partition auf dem S3 ist ~10 MB, also völlig ausreichend; die ,,1 MB" aus der Meldung war nur das (falsch gesetzte) Upload-Limit.

In v0.8.4 ist das Limit angehoben — der manuelle ,,Flash web UI" funktioniert dann mit dem großen S3-Image. Ich hab das auf einem S3-Testgerät einmal komplett durchgespielt: ~9,9-MB-Image manuell hochgeladen → sauber geschrieben (~80 s) → Reboot → UI intakt.

Zum Online-Update, das ,,gar nicht erst losläuft": das war der Updater-Stand der 0.8.0 selbst (der Install-Button hing am gecachten Prüf-Status). Ab 0.8.3 behoben — aber ein 0.8.0-Gerät kann sich diesen Fix nicht selbst per OTA holen, daher war dein einmaliger USB-Weg mit Erase genau richtig. Jetzt, wo du auf 0.8.3 bist, läuft das Online-Update künftig normal durch.

Deine Anregung mit dem GitHub-Link: ist drin — Footer-Link zur Projektseite in der WebUI und auf sixback.io, ebenfalls ab v0.8.4.

Schön, dass DLNA-Browser und die ausklappbare Übersicht bei dir laufen!

Gruß

fred_feuerstein

#22
Was mir so generell aufgefallen ist:

Handling klappt insgesamt recht gut. Nur nach einem Fresh-Install bei der vielzahl an Bose Devices bei mir, da hakt es recht schnell an verschiedenen Stellen. Auch wurden nicht alle Presets, vor allem die auf DLNA Quelle (obwohl verfügbar) korrekt angezeigt und waren auch nicht mehr abspielbar.
Ein DLNA Drag/Drop auf einen Preset hat vermeintlich funktioniert, aber am Lautsprecher ging es dann trotzdem nicht.
Habe in diesen Fällen dann über die Bose-App die Playlist vom DLNA gestartet und dann manuell am Bose Gerät die Speichertaste gedrückt. Dann ging es wieder.

Nun ändert man ja nicht laufend alles neu. Von daher ist das Handling auch wieder ok.

Also soweit alles prima. Momentan.

- DLNA funktioniert
- Spotify funktioniert
- Webradio ohnehin...

Jetzt erstmal wieder ein bisschen Musik hören :D


Ach so: Update auf 0.8.4 hat wieder OTA funktioniert.
Aber danach waren meine 9 Lautsprecher nicht mehr da. Der Scan, der vorher seit Tagen immer alle 9 gefunden hat, findet aktuell keinen einzigen Lautsprecher mehr.
OK. Ich lass den sixback nun mal ein bisschen laufen. Vielleicht findet er später wieder was. (wollte jetzt nicht 9 mal manuell hinzufügen...)



Gruß, Fred

NEU: FHEM auf Raspberry PI 5, OS: Bookworm, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art

tostmann

Zitat von: fred_feuersteinUpdate auf 0.8.4 hat wieder OTA funktioniert. Aber danach waren meine 9 Lautsprecher nicht mehr da. Der Scan, der vorher seit Tagen immer alle 9 gefunden hat, findet aktuell keinen einzigen Lautsprecher mehr.

Danke für die ausführliche Rückmeldung — und schön zu lesen, dass DLNA, Spotify und Webradio bei dir soweit laufen. Den Workaround (in der Bose-App vom DLNA starten und dann am Gerät die Speichertaste drücken) kenne ich; den DLNA-Push direkt aus SixBack sauber hinzubekommen ist noch eine eigene Baustelle, da bleibe ich dran.

Zur verschwundenen Erkennung nach dem Update: ich habe den kompletten Diff von 0.8.0 auf 0.8.4 durchgesehen, gezielt auf den Discovery-Pfad. Am Scan selbst (SSDP/M-SEARCH und der Scan-Handler) wurde nichts geändert — der Umbau in diesem Sprung betraf nur das HTTP-Routing (ich habe die Regex-Engine rausgeworfen, weil sie auf den kleinen C3/C6 den Speicher sprengt und Bootloops auslöst) sowie die Partitionierung. Es gibt also keine bewusste Änderung, die die Lautsprecher-Suche lahmlegen würde.

Mein Verdacht ist deshalb ein vorübergehender Zustand direkt nach dem OTA-Neustart: dass der Multicast-/IGMP-Beitritt nach dem Reboot nicht sauber zustande kommt und die M-SEARCH-Antworten der Boxen schlicht nicht ankommen. Das würde dazu passen, dass vorher tagelang alle 9 zuverlässig gefunden wurden und sich an der Suche im Code nichts geändert hat.

Damit ich das messen statt raten kann, zwei kurze Sachen:

  • Mach den Stick einmal richtig stromlos (Netzteil ziehen, ~10 s warten, wieder einstecken — nicht nur den Reset-Knopf) und starte danach den Scan neu. Kommen die 9 dann wieder? Falls ja, war es genau dieser Zustand nach dem OTA-Reboot.
  • Falls du ohnehin seriell drankommst (115200 Baud): schick mir beim Scan die Zeilen ab [inv][ssdp] M-SEARCH burst sent, listening 4s .... Wenn diese Zeile erscheint, aber danach keine Treffer-Zeilen folgen, ist eindeutig die Multicast-Antwort das Problem und nicht der Code.

Wenn sich das bestätigt, ist die naheliegende Gegenmaßnahme ein erneuter Multicast-Join bzw. ein automatischer Scan-Retry kurz nach dem WiFi-Connect — das baue ich aber erst ein, wenn die Logs es zeigen, nicht auf Verdacht. Die 9 Boxen manuell neu anzulegen ersparst du dir damit hoffentlich.

Gruß, Dirk

fred_feuerstein

#24
Also auch nach längerem Strom abziehen und wieder einstecken hat es nicht funktioniert.
Teilweise nach dem Scan Versuch war der ESP gar nicht mehr erreichbar per Web.

Dann hier also mal ein Log nach dem Klick auf Scan:
[15:42:08][inv] discovery starting (sync phase)
[15:42:08][inv][ssdp] M-SEARCH burst sent, listening 4s ...
[15:42:08]Guru Meditation Error: Core  0 panic'ed (Unhandled debug exception).
[15:42:08]Debug exception reason: Stack canary watchpoint triggered (bg-discover)
[15:42:08]Core  0 register dump:
[15:42:08]PC      : 0x4037ea3a  PS      : 0x00060236  A0      : 0x80383324  A1      : 0x3fcca2e0 
[15:42:08]A2      : 0x3fcea3c4  A3      : 0xffffffff  A4      : 0xb33fffff  A5      : 0x403775ec 
[15:42:08]A6      : 0x00000001  A7      : 0x00000024  A8      : 0x00060223  A9      : 0x3fcca2e0 
[15:42:08]A10     : 0x00060223  A11     : 0x00000003  A12     : 0x00060223  A13     : 0x00060423 
[15:42:08]A14     : 0x0000003c  A15     : 0x0000cdcd  SAR     : 0x00000018  EXCCAUSE: 0x00000001 
[15:42:08]EXCVADDR: 0x00000000  LBEG    : 0x40056f5c  LEND    : 0x40056f72  LCOUNT  : 0xffffffff 
[15:42:08]
[15:42:08]
[15:42:08]Backtrace: 0x4037ea37:0x3fcca2e0 0x40383321:0x3fcca310 0x40383356:0x3fcca330 0x403834c0:0x3fcca350 0x403765b3:0x3fcca370 0x403765cd:0x3fcca3a0 0x40376749:0x3fcca3c0 0x403775f8:0x3fcca3e0 0x421147c2:0x3fcca400 0x421176c5:0x3fcca430 0x400398b5:0x3fcca460 0x42113d91:0x3fcca480 0x42113ef5:0x3fcca4b0 0x420cb1a9:0x3fcca4f0 0x4209bf3e:0x3fcca510 0x4208d752:0x3fcca530 0x420ade32:0x3fcca560 0x42085d15:0x3fcca580 0x4207dcca:0x3fcca5a0 0x4207e0b5:0x3fcca5d0 0x4207e20f:0x3fcca600 0x4207e426:0x3fcca630 0x4207f31d:0x3fcca660 0x4207f359:0x3fcca6a0 0x4207f37f:0x3fcca6d0 0x4207b52d:0x3fcca700 0x42077a19:0x3fcca740 0x42088b7f:0x3fcca770 0x420741b8:0x3fcca790 0x4208774f:0x3fcca7b0 0x42087903:0x3fcca7d0 0x42072de9:0x3fcca820 0x4200723b:0x3fcca860 0x4200674a:0x3fcca8d0 0x4200c1b9:0x3fcca930 0x4200dfca:0x3fcca960 0x4200e2a7:0x3fcca9c0 0x4204f4a6:0x3fcca9e0 0x42052006:0x3fccab70 0x420529f8:0x3fccb100 0x4201b37e:0x3fccb140 0x4037e935:0x3fccb160
[15:42:08]
[15:42:08]
[15:42:08]
[15:42:08]
[15:42:08]ELF file SHA256: 7327ee12e
[15:42:08]
[15:42:09]Rebooting...
[15:42:09]ESP-ROM:esp32s3-20210327
[15:42:09]Build:Mar 27 2021
[15:42:09]rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
[15:42:09]Saved PC:0x4037dc61
[15:42:09]SPIWP:0xee
[15:42:09]mode:DIO, clock div:1
[15:42:09]load:0x3fce2820,len:0x10cc
[15:42:09]load:0x403c8700,len:0xc2c
[15:42:09]load:0x403cb700,len:0x30c0
[15:42:09]entry 0x403c88b8
[15:42:09]
[15:42:09]=========================================
[15:42:09]  SixBack 0.8.4
[15:42:09]  Build: 2026-05-29 11:19:39
[15:42:09]  Copyright (c) 2026 Dirk Tostmann
[15:42:09]  License: PolyForm Noncommercial 1.0.0
[15:42:09]  Commercial use prohibited — see LICENSE
[15:42:09]=========================================
[15:42:09][mbedtls] PSRAM allocator installed (threshold=512, psram_free=8188 KB)
[15:42:09][fs]   LittleFS mounted, 176128/10354688 bytes used
[15:42:09][   590][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND
[15:42:09][improv] starting (idle-window 30s, NVS-creds present)
[15:42:10][wifi] NVS credentials present, trying ssid=hannebambel HOME
[15:42:11][wifi] connected, IP=192.168.123.173
[15:42:11][wifi] PS=NONE TX=max CPU=240 MHz — optimized for reliability
[15:42:11][improv] reset window after AP connect — improvLastActivityMs=2385 improvActive=1
[15:42:11][wifi] up, IP=192.168.123.173 MAC=1C:DB:D4:74:9F:44 RSSI=-73
[15:42:11][mdns] sixback.local advertised
[15:42:11][  2398][E][Preferences.cpp:506] getString(): nvs_get_str len fail: speakers NOT_FOUND
[15:42:11][inv] no NVS-state, starting fresh
[15:42:11][  2417][E][Preferences.cpp:506] getString(): nvs_get_str len fail: presets NOT_FOUND
[15:42:11][inv]  0 known speakers, presets loaded
[15:42:11][failsafe] IP unchanged (192.168.123.173) — nothing to do
[15:42:11][  2428][E][Preferences.cpp:506] getString(): nvs_get_str len fail: slots NOT_FOUND
[15:42:11][spot] no NVS slot-map, start empty
[15:42:11][  2444][E][Preferences.cpp:506] getString(): nvs_get_str len fail: library NOT_FOUND
[15:42:11][spot] no NVS library, start empty
[15:42:11][spot/worker] running
[15:42:11][spot] init done — preset-pressed callback registered, TLS-clients ready, worker spawned
[15:42:11][bose] cloud-replacement listening on :8000
[15:42:11][bose] tell speakers to use: http://192.168.123.173:8000
[15:42:11][ui]   web/api listening on http://192.168.123.173:80/
[15:42:11][ui]   mDNS: http://sixback.local/
[15:42:11][health] boot #12  last-reset=PANIC  crashes-lifetime=7  wifi-reboots=0  heap-reboots=0
[15:42:11][health] task-wdt subscribed=1 (timeout=30s)
[15:42:11][auto] startup  enabled=0  bootDelayMs=10000  dryRun=0  maxPerBoot=4  cronIntervalS=1800
[15:42:11][auto] disabled at boot — task stays alive but idle (re-enable + reboot or wait for cron tick reload)
[15:42:11]
[15:42:11][setup] SixBack ready - UI: http://sixback.local/
[15:42:11][setup] Trigger speaker discovery: curl -X POST http://sixback.local/api/speakers/discover
[15:42:16][  7390][E][Preferences.cpp:47] begin(): nvs_open failed: NOT_FOUND

Habe jetzt die 9 Boxen manuell hinzugefügt. Das hat fehlerfrei funktioniert. Keine Ahnung warum der Scan gar nichts gefunden hat.

Als Idee: Bei Bosman und opensoundcloud kann man IP-Adressen von lautsprechern speichern, die bei Bedarf (wenn nicht automatisch per scan gefunden) dann "automatisch" manuell vom System hinzugefügt werden.
Vielleicht könnte man hier auch so eine IP-Liste pflegen.

Denn ich musste eben nochmal den Stecker ziehen und nach Start sind erneut keinerlei Lautsprecher zu sehen....
Gruß, Fred

NEU: FHEM auf Raspberry PI 5, OS: Bookworm, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art

tostmann

Danke fürs serielle Log — das war genau der fehlende Baustein, und es war kein Multicast-Problem, wie ich zuerst vermutet hatte. Der entscheidende Hinweis steht ganz oben in Deinem Dump:

Debug exception reason: Stack canary watchpoint triggered (bg-discover)
Der Name in der Klammer ist der Task, der den Scan im Hintergrund fährt. Heißt: der Discovery-Task ist seinen Stack übergelaufen und das Gerät hat sich mitten im Scan neu gestartet. Danach ist das Speaker-Inventar leer — daher ,,findet 0 von 9", während das manuelle Hinzufügen (ein komplett anderer Code-Pfad) weiterhin geklappt hat. Das passt exakt zu dem, was Du beschrieben hast.

Was das Log sonst noch zeigt, die Zeilen mit
Preferences.cpp ... nvs_open failed: NOT_FOUND, ist übrigens harmlos — das ist nur der normale ,,diesen NVS-Namespace gibt es noch nicht"-Hinweis direkt nach einem frischen Flash, kein Defekt.

Warum es Dich trifft und die kleinen Testaufbauten nicht: je mehr Speaker auf den SSDP-Burst antworten, desto tiefer wird der Aufrufstapel im Scan — bei 9 Geräten reicht das, um den Stack zu sprengen, bei 2-3 nicht.

Gefixt in v0.8.5: der Discovery-Task sammelt die SSDP-Antworten jetzt erst ein und probt die Speaker danach (vorher mitten in der Empfangsschleife, mit dem 1-KB-Empfangspuffer noch auf dem Stack), und der Task-Stack wurde verdoppelt. Auf S3, C6 und C3 läuft der Scan damit sauber durch und findet alle Speaker.

v0.8.5 ist bereits online. Du kannst direkt per OTA aktualisieren — kein USB nötig, keine Partitions-Änderung. Nach dem Update sollte der Scan Deine 9 wieder von allein finden, ohne manuelles Nachtragen. Falls bei Dir mit 9 Geräten wider Erwarten doch noch etwas hakt, schick nochmal ein kurzes serielles Log oder klick den Snapshot-Button, dann schaue ich weiter — ich konnte den Fix hier nur bis 3 Speaker gegentesten, das Überlauf-Verhalten selbst ist aber raus.

Noch mit drin in v0.8.5 (das war GitHub #8): Deine selbst angelegten Stream-Kacheln liegen jetzt im Gerät (NVS) statt nur im Browser — sie überstehen also einen USB-Erase und einen Browserwechsel, inklusive Export/Import.

Grüße!


fred_feuerstein

Nach Update auf die 0.8.5 waren alle Lautsprecher sofort da! Scheint also funktioniert zu haben :)
Und die Import/Export Funktion bei dem Direkt-Streams und der erstmalige Import der Browser-Streams hat funktioniert.

Hatte im Issue zu den "Verbessungen bei vielen Lautsprechern" noch ergänzt als Comment, ob es möglich wäre, die Sortierung der Speaker zu ändern. Beispielsweise man pickt einen Speaker und schiebt ihn hoch oder runter.

Solange das mit dem Finden der Lautsprecher wieder gut funktioniert, braucht man denke ich auch keine anzulegende IP-Listen-Möglichkeit, die dann vom sixback nach und nach geadded wird. Schauen wir also mal wie es sich weiter verhält.


Ich muss das mit DLNA die Tage noch mal genauer testen. Hatte jetzt schon Fälle, da konnten Kacheln von meinem Standard-DLNA (Fritzbox), obwohl es eine alte Box war mit eingerichtetem STORAGE_MUSIC für die Fritzbox, dann nicht richtig gespeichert und abgespielt werden.

Habe meine Backup Box, die noch keinen festen Platz hat, mal neben meinen Arbeitsplatz geholt, da kann ich nebenbei immer mal was probieren.

Wenn mir was auffällt, notiere ich es mal auf meinem virtuellen Zettel.


Weisst Du eigentlich wieviele User sixback nutzen? Würde mich mal interessieren, weil ja sonst kaum Rückmeldungen kommen. Weder hier noch bei Github, oder? :)
Gruß, Fred

NEU: FHEM auf Raspberry PI 5, OS: Bookworm, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art