meshbay.git/packages/meshbay-hub/src, branch 0.7

fix(hub): poll for a root count change instead of trusting one fetch

2026-08-24T22:29:03Z

Point 1 (directory list not updating without a full page reload) turned out to still reproduce after the earlier onRefreshIndex fix — that one addressed the Videos/Music root pickers (nodeDirs), but this section's own list reads a different field entirely (ops.list_groups returns the *runtime* root set, groups_ctx[gid]["roots"]) that only gets replaced once _reload_config_inner's retarget actually finishes. /api/reload itself is fire-and-forget on the node by design (ops.start_reload's own docstring — a brand-new group's initial scan can take minutes, the caller must not block on it), so a single loadNodeInfo() call right after can land in the gap before that replacement happens and show the pre-change count. Both the add and remove handlers now poll /api/groups (up to ~4s, every 400ms) until the root count actually matches what the action should have produced, rather than fetching once and hoping the timing worked out.

fix(hub): keep an unmatched admin_challenge visible, add trace logging

2026-08-24T21:47:01Z

A real report showed audio_root timing out with *nothing* logged in between the connection handshake and the timeout — no admin_challenge, no error, nothing. The previous fix made an unmatched admin_challenge return silently (correctly, to stop it stealing an unrelated pending request — see the earlier commit), but that silence is indistinguishable from "the request never reached the node at all", which is exactly the ambiguity blocking this investigation. An unmatched admin_challenge is now logged (op, op_id, and the full set of currently-pending keys) instead of dropped quietly, and setAudioRoot/_authorizeAdminOp trace both hops of the round trip explicitly. Node-side, _do_audio_root gets a debug log at entry — cheap, and the only way to know from server logs alone whether the request was ever received if the client-side trail comes up empty. Diagnostic only: no routing behavior changed from the previous fix, verified against the same reproduction script.

fix(hub): make root-folder save success/failure actually visible

2026-08-24T21:35:09Z

Flagged directly: "Saving" ran for a few seconds then just stopped, with nothing telling the operator whether it had worked. Both outcomes used the same dim .settings-hint styling, so a real failure and a real success looked identical at a glance. Success and failure are now tracked separately (previously one plain string held either) and rendered with the same success-msg/error-msg styling already used elsewhere on this page, so which one happened is unambiguous.

fix(hub): key admin_challenge/admin_response by op, not arrival order

2026-08-24T21:09:28Z

Reproduced from a real report: enabling the Music app and saving its root folder in the same Settings visit (the new merged Directories section makes this a fast, natural back-to-back sequence) fired two signed admin ops within milliseconds. Neither the admin_challenge reply nor the admin_response ack two steps later was keyed by anything — both were matched purely by "whichever request happens to be oldest pending" (transport.js's own documented last-resort guess). apps_enabled's challenge stole audio_root's pending slot; audio_root's own request never received a challenge at all and just sat there until its 30s timeout. Both hops are now keyed by op name: admin_challenge already carries `op` from the node, and admin_response is given one client-side purely for this (the node's _do_admin_response never reads it — only op_id and signature). A stray admin_challenge with no matching request is dropped outright rather than guessed at — it is never a broadcast (one `self._send`, no peer loop, docs/webrtc_server.py), so a session with no matching key genuinely has nothing to do with it. A domain ack (an actual broadcast — every connected client gets audio_root_ack, not just the requester) still falls through to the existing per-type handling when nobody here is waiting on it, unchanged. Verified against a standalone reproduction of the exact race (two admin ops racing, reordered replies) — this codebase has no browser-JS test runner to add as a real regression test, so the repro lived in a scratch script rather than the suite.

fix(hub): refresh directory list after adding/removing a shared root

2026-08-24T21:09:13Z

Folders (unlike files) only ever arrive over MNP as part of a full index_sync — the ongoing index_delta push has no `dirs` field at all (daemon.py never puts one there for incremental updates) — so a directory added or removed via the Electron-local add/remove flow never showed up in the Videos/Music root pickers until the whole page was reloaded. The merged Directories section made this easy to hit: add a shared folder, then immediately try to pick it as a root, in the same visit. Both actions now call the same onRefreshIndex a chat upload already uses to pick up its own effect on the index.

feat(hub): audio_root wiring, mutually-exclusive players, Settings rework

2026-08-24T20:44:27Z

Five related pieces of polish against the Music app and Settings, all from the same conversation: - Music app now requires audio_root, same as Videos requires video_root: an empty-state message until one is set, and grouping filtered to only what's under it (underAudioRoot, mirroring video-app.js's underVideoRoot). Wires the new audio_root/audio_root_ack pair through transport.js and group-page.js state the same way video_root already flows. - Starting one player now stops the other — opening a film closes the music queue, starting a track closes the video modal. Both used to run at once, found live. - Group Settings reworked: every section but a bare form (invite, pair-operator, approve-device) is now collapsible (CollapsibleSection); the uploads on/off button is a real toggle switch (ToggleSwitch, reused for TMDB/MusicBrainz's enabled switches too, each now with an icon + status badge in its header instead of a plain checkbox row); and shared directories, the Videos root picker, and the new Music root picker are merged into one "Directories" section (RootFolderRow) instead of three separate ones scattered down the page — the root pickers only show once their app is actually enabled.

fix(hub): give the Music flat list its own look instead of Videos' reskin

2026-08-24T19:51:18Z

Two complaints against real use: the artist -> album -> track hierarchy was invisible (every depth sat flush left, distinguishable only by which chevron happened to be open — Videos' own flat list never needed more than one level, so there was nothing to reuse for this), and a filled-in album unfolded into a wall of identical little icon-box squares, one per track, carrying no information a track row can actually use (unlike Videos' per-episode thumbnail). Track rows now reuse Mode A's own numbered tracklist style (.music-track-row: number, title, duration, no icon box) instead of Videos' boxy thumb-slot row. A folder's expanded contents get wrapped in a new .music-flat-children indent + rule line, so nesting reads as visible steps into the tree rather than same-level siblings. Folder rows (artist/album headers) still reuse Videos' flat-row style, which fits them fine — this is not a wholesale rewrite, only what didn't actually work.

fix(hub): starting one player stops the other

2026-08-24T19:51:18Z

Opening a film while a track was playing left both audio tracks running together — nothing closed the music queue when a video opened, and nothing closed the video modal when a track started. Both directions now stop whichever player wasn't just asked for.

fix(hub): show what's actually playing in the queue panel

2026-08-24T19:24:30Z

The panel's header said "Playing now" but only the panel itself was named that — the current track was just a highlighted row you had to spot in the list, easy to miss on a long queue and often scrolled out of view entirely on open. Now shows the track's own title/artist right under the header and scrolls the highlighted row into view when the panel opens.

feat(music): transcode WMA/Musepack to AAC so they actually play

2026-08-24T19:08:34Z

Tagging and covers for these two formats landed already, but neither one decodes in any mainstream browser's element at all — a real library scan turned up 273 such files that would show up correctly in the Music app and then simply fail on click. This closes that gap: the node transcodes to AAC/M4A on request (a one-shot whole-file conversion, not live-piped like video's fMP4 segments — an audio file is small enough that streaming it buys nothing), caches the result under its own content hash the same way a TMDB poster or a MusicBrainz cover is cached, and serves it back through the ordinary file_req/chunk path. That path used to assume anything in the media cache was thumbnail-sized (single chunk, always); generalized it to slice a cached blob the same way a real file on disk gets sliced, since a transcoded track can be several MB. New MNP pair (`audio_transcode_req`/`_resp`, version bump to 0.9), shares its concurrency cap with video's transcode pool rather than getting its own — both are real ffmpeg processes on the same node. Every other audio format is untouched: this only fires for .wma/.mpc, the two extensions that need it.