feat: play your network music library on the speaker, plus four carried-over fixes

[JRpersonal]

Four fixes, all verified against live hardware or by test.

1. SSH unlock on a stock speaker survives the reboot

buildBootstrapEnableSSHCommands issued envswitch before sys configuration. envswitch commits the runtime layer as it stands when it runs, so the sys configuration write that followed was discarded at the next boot.

• The fallback we believed we had for chassis we cannot measure ourselves was never actually there.
• bmxRegistryUrl and statsServerUrl have no envswitch form at all, so sys configuration is their only route and it never persisted.

Measured by @bitranox on a SoundTouch 20 (spotty, FW 27.0.6) in gesellix/Bose-SoundTouch#471. The method is why it is trusted: an already-migrated box was poisoned first, all four URLs pointed at an unreachable address and confirmed to survive a reboot of their own, so a pass could not be inherited from existing config.

Confirmed live on a stock rhino ST10, no stick, SSH closed, which is the only state that runs this path: SSH opened 72 s after the reboot. The order is now pinned by the test.

2. Undoing a stereo pair reaches both speakers

Undo went only to the speaker recorded as pair master, on the understanding that the master is the half that knows about the pair. Measured 2026-08-10 on two SoundTouch 10s, that stops being true once one half lets go: the master answered /getGroup with <group /> while the other speaker still held the whole document naming the master as LEFT, status GROUP_ERROR.

.48 (recorded master) /getGroup -> <group />
.49                   /getGroup -> <group id="str-grp-..."> ... <status>GROUP_ERROR</status>

So every undo was told "nothing to undo" while the panel simultaneously named the pair, and the leftover could not be cleared from the app at all. Sending DELETE /api/box/zone?stereo=1 to .49 cleared both speakers in one call, so the agent-side teardown was already correct; only the addressing was wrong.

Both halves now get the undo, master first. A speaker that is not in a pair answers "nothing to undo" and is left alone, so the only behaviour that changes is the stuck case. Target selection moved into groups.js as stereoUndoTargets and is covered by tests.

3. The diagnostic report records which inputs and services a speaker has

A CineMate 130 owner reported that the "offer every input" feature still showed him Bluetooth alone (discussion #577), and his report could not say why: nothing in a bundle described his inputs.

/sources is now captured per box. Linked streaming accounts are hashed like the other personal data (ACCT#...), while socket labels (AUX, TV, CBL-Sat) and the firmware's ...UserName placeholder slots stay readable, since those are the part that has to be readable for the field to be worth anything.

4. Stray code in the Multi-Room panel

The fillPairBalance call sat inside the innerHTML template literal instead of after it, so the page printed the line verbatim and the balance never loaded.

Verification

• go build ./... clean, go vet clean, gofmt clean
• go test ./... in desktop-app passes
• npm test in desktop-app/frontend: 102 tests pass
• Live: telnet path on a stock ST10; stereo dissolve on .48/.49, both now report {"members":[]}

[JRpersonal]

Added: network music library as a native speaker source

A speaker can see the DLNA/UPnP media servers on the LAN by itself (GET :8090/listMediaServers) but will not play from one until that server is registered as a STORED_MUSIC account. STR now does that registration, from the desktop app (Speaker settings) and from the phone remote (Speakers tab).

Once registered the speaker browses and plays the library natively: no stream proxy, no UPnP push from STR, and the library also appears in the original Bose app.

The wire format, since none of it is in Bose'"'"'s public API doc

POST :8090/setMusicServiceAccount          (POST, not PUT: PUT answers 405)
<credentials source="STORED_MUSIC" displayName="AVM FRITZ!Mediaserver">
  <user>fa095ecc-...-3C37129F8346/0</user><pass></pass>
</credentials>

The account is the server id from /listMediaServers (the UDN without the uuid: prefix) with /0 appended. The box answers 200, then calls back to STR'"'"'s marge with addSource, which respondAddSource already handled, and only then does the source turn READY.

Browsing (POST :8090/navigate) descends only through an <item> carrying <name> and <type> before its <ContentItem>. A bare <ContentItem> or a <mediaItemContainer> as a direct child is rejected with field not found on '"'"'navigate'"'"'.

The part that needed STR

The registration does not survive a reboot: measured, the source is present for the first ~70 s of the boot and then disappears, because the box re-checks the account against marge and STR'"'"'s record of it lived only in memory. So the user'"'"'s choice is persisted (internal/mediaservers) and reapplied once at agent start. That path reads before it writes and writes nothing when nothing is missing, so it cannot hold a speaker out of deep standby.

Verified on hardware (Portable, FRITZ!Box 6690)

• registered, source went status="READY", agent logged addSource callback answered ... askedProvider=7
• browsed root (Musik, Bilder, Filme, Internetradio, Podcasts, Datei-Index) and down to a track
• played it natively: source=STORED_MUSIC track="Fly FRITZ! Fly" artist="AVM GmbH" PLAY_STATE
• rebooted, and STR put it back on its own: media server: music source restored after the restart, still READY a minute later
• canaries AUX and LOCAL_INTERNET_RADIO stayed READY throughout

New UI strings are in all 12 locales in both interfaces. wails generate module was run and the bindings are committed.

[JRpersonal]

Correction: the registration is a PULL, not a push

Jens pointed out that the original design registered a media server per Bose account and that the boxes polled for it, the way radio arrives, rather than the cloud pushing to them. That is right, and the marge request log proves it. At boot the box does:

GET /streaming/account/stick@local/full        <- its own poll
(no /sources read, and no POST .../source at all)

The box reads the account document and keeps whatever sources it advertises. So putting a media server in that document IS the persistence mechanism. storedMusicSourcesXML now renders the enabled servers into /full, /account and the account sources list, seeded from the NAND store at agent start.

Verified by removing the source from the speaker entirely (/removeMusicServiceAccount), restarting the agent, and watching the box bring it back on its own: READY, browsing still working, and zero media server lines in the agent log, because nothing was pushed.

This deletes the push-based ReapplyMediaServers and with it every write on the persistence path, so that path can no longer touch the standby countdown at all.

The push to /setMusicServiceAccount is kept for one thing only: making a server usable at the moment somebody enables it, instead of at the next boot. Two things had to change there:

• pushing a server the box already has answers 500 / 1024, so /sources is read first and the push skipped. The previous code reported a perfectly healthy source as a failure.
• the store and the account publish happen BEFORE the push, since that half cannot fail on the box. A refused push now leaves a setting that still works after the next restart.

The source shape is pinned by a test against staticRadioSourceXML: same elements in the same order, differing only in the provider id (7), the sourcename (STORED_MUSIC) and the username. A source rendered into /full that omits an element is the documented way to break the whole account document rather than just that entry.

One cosmetic difference: a pulled source shows in /sources as STORED_MUSIC, a pushed one as "AVM FRITZ!Mediaserver". The firmware takes that text from sourcename and not from <name>, exactly as it does for radio (<name> is "Local Internet Radio", the sourceItem says LOCAL_INTERNET_RADIO). Whether the Bose app shows the friendlier name is unconfirmed.