docker pull ghcr.io/maziggy/bambuddy:daily

or

docker pull maziggy/bambuddy:daily

**Tip:** Use [Watchtower](https://containrrr.dev/watchtower/) to automatically update when new daily builds are pushed.

Added

• VP wire-payload dump escape hatch for shape-of-payload triage (#1622 investigation) — When a virtual printer in non-proxy mode is misbehaving for the slicer-facing surface (AMS slot fields rendering empty, filament dropdown unselectable, K-profile not visible), the existing logs prove the bridge is bound and pushing at 1Hz but don't show what's actually in the wire payload. Without that, "cache is missing fields" is indistinguishable from "the slicer-facing copy is stripping them." Set BAMBUDDY_VP_DUMP_WIRE=1 and Bambuddy writes the bridge's cached push_status (<log_dir>/vp_wire/<vp_name>_in.json) and the periodic 1Hz copy that gets sent to the slicer (<log_dir>/vp_wire/<vp_name>_out.json) to disk, overwritten on each tick. Diffing the two answers the bisect question; diffing a misbehaving VP's _out.json against a known-good VP's _out.json (e.g. P1S vs H2D in the #1622 case) answers the model-shape question. Off by default, no overhead when disabled (single env-var read per tick); env var re-read on every call so toggling without restart works; failures swallowed at debug so a broken dump can never break the 1Hz loop. Implementation lives in backend/app/services/virtual_printer/_debug.py with call sites in mqtt_server.py::_send_status_report (cached branch only — synthetic fallback is uninteresting for this triage) and mqtt_bridge.py::_on_printer_raw (immediately after the merge that produces _latest_print_state). 21 unit tests in test_vp_wire_dump.py pin: disabled-by-default, atomic tmp+rename writes (no half-written .json visible to a reader), sanitized vp_name (path-separator stripped, empty name falls back to vp, .. inside a single filename component is harmless because slashes are collapsed before path construction), per-call env check, dict + bytes + str payload acceptance, swallow-on-OSError. Not gated on debug-logging because the bridge's verbose path is already noisy; this dump is small (one file per direction per VP) and only present when the operator opts in. Diagnostic-only — does not change the bridge data path.
• VP slicer↔printer command-flow trace (#1622 round 2) — The snapshot dump above answers "is the cached push shape correct?", but the round-1 captures from #1622 ruled that out: P1S AMS payload reaches the slicer byte-identical to what the printer sent, sticky-key preservation works, the visible slot data is intact. The remaining symptom (picking a generic filament in archive mode "unloads" the slot) lives on the command path, not in the periodic push — and the snapshot dump doesn't capture command traffic. Same env flag (BAMBUDDY_VP_DUMP_WIRE=1) now also appends every slicer-originated publish on device/<vp_serial>/request AND every printer-originated response the bridge fans out to the slicer (extrusion_cali_get, ams_filament_setting acks, xcam, system, etc.) to <log_dir>/vp_wire/<vp_name>_cmd.jsonl, one JSON line per event with UTC iso timestamp, direction (slicer_to_bridge / printer_to_slicer), MQTT topic, a <channel>.<command> grep handle, and the parsed payload. Excludes the cached-as-base 1Hz push (already covered by the snapshot dump) and pushall/get_version (handled locally, never forwarded). Printer-side captures happen AFTER serial rewrite so the dump matches what the slicer actually saw on the wire. New append_event helper in _debug.py mirrors the same swallow-on-OSError + sanitized-vp_name + per-call env-check posture as dump_wire; bytes payloads are utf-8 decoded then json-parsed with the same \x00-tolerance fix from #927 so OrcaSlicer's C-string-null publishes parse cleanly; un-parseable bytes fall back to {"raw": "..."} so every line stays valid JSON. Eight additional unit tests in test_vp_wire_dump.py pin: disabled-by-default, bytes parsing, trailing-null tolerance, unparseable-fallback, vp_name sanitization, iso timestamp shape, append-multiple-lines, swallow-on-OSError. Diagnostic-only — does not change the publish or fan-out data path.
• VP bridge-synthesised reply trace (#1622 round 3) — The round-2 cmd.jsonl from shaddowlink's P1S vs H2D capture proves the actual failure mode: on P1S in archive mode the slicer issues extrusion_cali_set (push K/n directly) and the printer responds fail, on H2D and on the P1S second round the slicer takes the extrusion_cali_sel flow (select by filament_id / cali_idx) and the printer responds success. Both flows traverse the bridge cleanly — ams_filament_setting round-trips with result=success and the cached push_status carries tray_info_idx=GFA11, tray_type=PLA-AERO, K/n, and cali_idx=-1 intact. So the bridge is innocent on every layer the dump can see, and the open question becomes: what makes the slicer pick _set vs _sel? Likely candidates are the info.get_version answer Bambuddy synthesises (slicer fingerprints on sw_ver / hw_ver / module to decide its command flow) or the first cached pushall response the slicer reads to bootstrap its UI. Round 2 captured neither — the JSONL had slicer_to_bridge and printer_to_slicer directions but no bridge_to_slicer direction for the bridge's own synthesised replies. Same env flag (BAMBUDDY_VP_DUMP_WIRE=1) now also appends every bridge-synthesised reply (info.get_version answer, project_file ack, on-demand pushall response) to <log_dir>/vp_wire/<vp_name>_cmd.jsonl under direction bridge_to_slicer. Capture lives in mqtt_server.py::_publish_to_report — the single chokepoint every synthesised reply already passes through — gated on a new log_event: bool = True parameter; the 1Hz periodic-push path threads log_event=False so the JSONL isn't flooded with ~60 lines/min per VP (snapshot dump already covers cache shape). The on-demand pushall response from _send_status_report IS logged because that's the bootstrap-fingerprint reply the slicer reads on first connect. Two additional unit tests in test_vp_mqtt_bridge.py::TestWireFormat pin the event-on-default and skip-when-log_event=False posture; test_vp_wire_dump.py already covers the underlying append_event shape and the new direction is documented in _debug.py's docstring. Diagnostic-only — does not change the publish data path; the new param defaults preserve every existing call site's behaviour.
• Windows installer build pipeline scaffolded — Lays down the infrastructure for producing a self-contained Bambuddy Windows installer .exe that doesn't require Python, Node, or any other runtime on the target machine. The installer ships an embedded Python 3.13 distribution (matching the Dockerfile's python:3.13-slim-trixie), the pre-built React bundle, NSSM (service supervisor), and ffmpeg — everything Bambuddy needs to run end-to-end on a stock Windows 10/11 box. Architecture: install target C:\Program Files\Bambuddy\, data target C:\ProgramData\Bambuddy\data\ (preserved on uninstall so reinstalls keep the database + archives), service registered via NSSM running as LocalSystem with autostart on boot (LocalSystem is required because the Virtual Printer feature needs to bind 322 / 990 / 8883, all privileged ports on Windows). Browser is the UI — Start Menu shortcut opens http://localhost:8000, no Tauri / Electron launcher in v1, which matches how every other Bambuddy platform already works. Why this shape over a PowerShell install.ps1: the script approach was tried first and abandoned. Each failure across the Windows host fleet is environmental drift (Python version mismatches, execution-policy variants, antivirus heuristics, missing MSVC runtimes, OneDrive-redirected %APPDATA%, ARM64 vs x64, PowerShell 5.1 vs 7.x semantics) — a script can't insulate against host state, and every fix you add for one machine breaks two others. The self-contained-bundle approach takes that whole class of failure off the table. Files: installers/windows/build.py stages everything under installers/windows/build/staging/, installers/windows/bambuddy.iss is the Inno Setup 6 script, installers/windows/service/install-service.bat + uninstall-service.bat wrap NSSM. build.py hard-fails on non-Windows hosts; cross-build under Wine is an unsupported escape hatch behind --allow-non-windows. CI: .github/workflows/windows-installer.yml runs on tag push (v*) and manual dispatch, uses windows-latest, downloads Inno Setup via Chocolatey, runs build.py + ISCC, uploads the .exe as both a workflow artifact and a release asset. Scope clarification: this commit lands the build infrastructure, not a verified-working installer. The first real Windows-box smoke test happens after merge by triggering the workflow manually and installing the artifact on a target box; known unknowns are pip-installing opencv-python-headless / curl_cffi / asyncpg / cryptography / bcrypt against embedded Python (the _pth file edits in build.py cover the common gotchas but real-runtime imports are where surprises surface), ffmpeg path lookup from a LocalSystem service, and NSSM AppEnvironmentExtra line-continuation in cmd.exe. Signing: v1 ships unsigned — Windows SmartScreen will warn "Windows protected your PC" on first run, click-through works. SignPath OSS application submitted 2026-06-10 to wire free EV signing into CI once approved (typical 1–3 week approval window). What's explicitly NOT in v1: Spoolman bundling (Bambuddy's internal-inventory mode is the v1 default on Windows; users who want Spoolman install it separately), in-place upgrade (uninstall + install cycle works, but in-place upgrade-on-top needs end-to-end verification before we promise it), port-conflict pre-check (deferred to v1.1 — port collisions surface at first service start and the user reads the NSSM stderr log under C:\ProgramData\Bambuddy\logs\service-stderr.log). See installers/windows/README.md for the full build pipeline.
• Bambu Lab A2L support (#1684) — Internal model code N9, serial prefix 26A19 (5 chars, same shape as H2C's late 31B8B). Capabilities resolved from BambuStudio's resources/profiles/BBL/machine/Bambu Lab A2L.json cross-checked against Bambu's official A2L specs page: linear rail, single FDM extruder + integrated cutter/plotter head (the BambuStudio use_double_extruder_default_texture: true flag covers the dual TOOL HEADS, not dual filament extrusion — A2L must NOT route AMS to the deputy slot or firmware rejects with 07FF_8012). Specs page also confirms NO Ethernet (Wi-Fi 2.4 GHz 802.11 b/g/n only), Low-Rate-Kamera on the chamber-image protocol (port 6000, NOT RTSP:322), no heated chamber. Registry updates: PRINTER_MODEL_MAP + PRINTER_MODEL_ID_MAP + LINEAR_RAIL_MODELS in utils/printer_models.py; MODEL_TO_API_KEY + API_KEY_TO_DEV_MODEL + API_KEY_TO_WIKI_PATH in firmware_check.py (wiki path follows the established /en/a2l/manual/a2l-firmware-release-history pattern; the existing 404 handling in _fetch_all_versions_from_wiki makes this safe to ship before Bambu publishes the page); VIRTUAL_PRINTER_MODELS + MODEL_SERIAL_PREFIXES in virtual_printer/manager.py (prefix 26A19A with the same revision-letter padding as X2D's 20P90A); MODEL_PRODUCT_NAMES in virtual_printer/mqtt_server.py; mapModelCode + Add-Printer / Edit-Printer model dropdowns in PrintersPage.tsx (new "A2 Series" optgroup); mapModelCode in SpoolBuddyAmsPage.tsx. Camera and dual-nozzle code paths need no edits: supports_rtsp() correctly falls through to chamber-image for A2L because N9 is neither in the internal-code RTSP set nor does the display name match the X1/X2/H2/P2 prefix tuple; is_dual_nozzle_model() correctly returns False because A2L is not in DUAL_NOZZLE_MODELS. The cutter/plotter capability surfaces in MQTT push fields Bambuddy doesn't yet model; ignored for v1, will surface as a follow-up only if a real-world A2L bundle reveals a confusing UI state. Tests: 12 new cases in test_printer_models.py::TestA2LModel pinning every dimension — rod type, model-id round-trip, both ethernet directions, both camera-port directions, the explicit non-dual-nozzle guard (regression guard for the BambuStudio profile flag misread), set membership in LINEAR_RAIL_MODELS and exclusion from CARBON_ROD_MODELS / STEEL_ROD_MODELS.
• One-shot device.* identification probe in MQTT push parser (#1684 enabler) — Adding support for a new Bambu printer model needs the internal model code the firmware sends in MQTT device.dev_model_name (e.g. A1 is N2S, H2C is O1C, X2D is N6). The field arrives on every push but Bambuddy never logged it, so even a debug-enabled support bundle from a new-model user (A2L on #1684 was the case that surfaced this) gave us no way to identify the model — get_version was also missing because the printer disconnected right after the request topic subscription, which is a separate firmware quirk. Fix: at the top of the existing device.* parsing block in bambu_mqtt.py, emit one INFO log per client session dumping dev_model_name / dev_product_name / dev_id / project_name if any are present; otherwise fall back to device.keys() so a future Bambu rename (e.g. model_name without the dev_ prefix) still surfaces. INFO level so the line lands in every support bundle, not just debug-enabled ones; one-shot via a _device_id_logged flag matching the existing _nozzle_fields_logged pattern at line 2095 — no spam at every push_status. 3 unit tests in TestDeviceIdentificationProbe pin the one-shot behaviour, the known-id-field path, and the keys-fallback path. Full test_bambu_mqtt.py suite 281 / 281 green; ruff clean. Once this ships, a new-model issue self-resolves from the first bundle — no second round of "please enable debug and reupload" required.
• Archives page banner: reactive install-step-4 nudge for the slicer-side setting — Companion to the new external_storage diagnostic check. The diagnostic catches the printer-side variant of "Store sent files on external storage" via home_flag bit 11. The slicer-side variant on older BambuStudio / OrcaSlicer never reaches the printer, so the diagnostic passes even when the option is off in the slicer. The deterministic symptom is the archiver creating a row with extra_data.no_3mf_available=True (main.py:2770) — that's the signal this banner watches. New backend endpoint GET /archives/no-3mf-warning returns {has_fallback: bool} — true iff any archive in the last 30 days has the flag set AND isn't soft-deleted. The 30-day window prevents old never-fixed installs from showing the banner forever; the soft-delete filter respects the user clearing the evidence. Frontend banner sits at the top of the Archives page (amber, dismissible) — "Some recent prints couldn't be archived with thumbnails…" + link to install step 4 in the wiki. Dismissal is one-shot via localStorage key archiveNo3MFWarningDismissed (matches the existing Layout.tsx update-banner pattern but persistent across sessions, since "you've been told" should outlive a browser restart). React-Query is enabled: !dismissed so the endpoint isn't polled after dismissal. 5 backend integration tests (TestNo3MFWarning) cover: recent fallback returns true, no archives returns false, archives without the flag returns false, >30-day-old fallbacks ignored, soft-deleted fallbacks ignored. i18n: 4 new keys (title, body, docsLink, dismissLabel) under archives.no3mfBanner translated to all 11 locales — no English fallbacks.
• Connection diagnostic now verifies install step 4 ("Store sent files on external storage") — Many users miss this setting when adding their first printer; without it BambuStudio / OrcaSlicer never leave a .gcode.3mf on the printer's SD card, every archived print falls back to no-thumbnail / no-metadata, and the cause is invisible until the user notices the archive is empty. The trap with detecting this: on newer firmware (P2S 01.02 / Bambu Studio 2.6+) the toggle moved onto the printer itself and is pushed on MQTT home_flag bit 11 (Bambuddy already parses this into state.store_to_sdcard). On older versions it's a purely slicer-side preference invisible to the printer. An FTP upload-probe approach was tried first — it always passed regardless of the slicer toggle because the /cache directory is always writable from Bambuddy's perspective; the slicer toggle only controls what BambuStudio chooses to do, not what the printer accepts from other clients. Confirmed empirically against an X1C + H2D with the slicer option toggled off (probe still succeeded, home_flag bit 11 stayed True). Fix: new external_storage check reads state.store_to_sdcard directly. Pass when the printer reports the bit on, fail when off, skip when no live MQTT state or the field has never been populated (older firmware that doesn't push home_flag). Localised fix-text points at install step 4 with both the printer-side and slicer-side variants spelled out; the skip text explicitly calls out the older-slicer limitation so users on that path know to verify manually. Slot in the check list sits between port_ftps and mqtt_auth. 5 new tests (TestExternalStorageCheck) cover pass-on-true, fail-on-false, skip-on-disconnect, skip-on-pre-add (no state), skip-on-missing-field. The reactive symptom-side detection — a one-time banner the first time the archiver records extra_data.no_3mf_available=True after a slicer-initiated print — is planned as a separate follow-up to cover the slicer-only setting case. Wiki updated on the System page (features/system-info.md) and the Troubleshooting page (reference/troubleshooting.md). i18n: 4 new keys (title, pass, fail, skip) localised to all 11 locales (de, en, es, fr, it, ja, ko, pt-BR, tr, zh-CN, zh-TW) — no English fallbacks.
• "Open in Slicer" desktop target is now configurable separately from the API sidecar slicer (#1329, reported by hasmar04) — Reporter wanted to slice via the Bambu Studio sidecar but open files locally in OrcaSlicer; the existing preferred_slicer setting drove both, so picking one forced the other. The slicer-URI flow on Workflow → Slicer literally swapped the BambuStudio handler for the OrcaSlicer one whenever the user switched the API choice. Fix: new open_in_slicer setting ('bambu_studio' | 'orcaslicer' | null) drives only the desktop "Open in Slicer" URI handoff; the in-app SliceModal + sidecar URL routing in library.py, archives.py, slicer_presets.py continue to use preferred_slicer exactly as before. Default is null — the frontend falls back to preferred_slicer so existing installs behave identically until a user changes it (no migration, no churn). Storage lives in the existing app_settings key/value table; the PUT path serialises a Python None as the literal string "None", and the GET path normalises it back via a new branch in _build_settings_response matching the existing default_printer_id convention — without that normalization the frontend can't tell "explicit override absent" from "explicit override set to a bogus value". Frontend: Settings → Slicer card relabels the existing dropdown's description ("Slicer used for in-app slicing via the API sidecar"), adds a new "Open in Slicer" dropdown below it with three options — "Same as API slicer" (the inherit-from-preferred default), "Bambu Studio", "OrcaSlicer". ArchivesPage (5 openInSlicerWithToken call sites), MakerworldPage (the URI handoff branch when useSlicerApi=false), and ModelViewerModal (4 openInSlicer(...) call sites) all switched from reading settings?.preferred_slicer to settings?.open_in_slicer ?? settings?.preferred_slicer. MakerworldPage's "Slice in {{slicer}}" button label additionally branches on useSlicerApi: when on, the label reflects the API slicer; when off, the desktop slicer — so the button text always matches what the button actually does. The OrcaSlicer "known CLI bugs" warning stays attached to the API dropdown (where it belongs — it's about the sidecar's CLI). i18n: 3 new keys in all 11 locales (de/en/es/fr/it/ja/ko/pt-BR/tr/zh-CN/zh-TW) — settings.openInSlicerLabel, settings.openInSlicerInherit, settings.openInSlicerDescription — plus an updated settings.preferredSlicerDescription everywhere (the old wording "Choose which slicer application to open files with" became wrong once the field stopped driving the desktop handoff). No English fallbacks per the project's hard rule. Tests: 3 new in TestOpenInSlicerOverride pin the contract — default is null, override persists across GET, explicit reset to null round-trips correctly without leaving the "None" string leak. Full backend suite green (5798/5798); frontend ESLint + build clean; vitest on SettingsPage + MakerworldPage 48/48 green; i18n parity 5095 leaves × 11 locales green.
• Queue items + Print modal now show the build plate type, per-plate accurate (#1281, reported by CMW-ISS) — Reporter on a multi-printer farm with 40+-plate runs needed to walk to the printer with the right physical plate; the archive card had recently grown a bed-type badge, but the queue and the scheduling modal didn't. They were having to open the source 3MF in the slicer to look up which plate each queued / scheduled job needs. Backend: new extract_bed_type_from_3mf(file_path, plate_id) helper in utils/threemf_tools.py, alongside the existing extract_filament_usage_from_3mf shape — reads Metadata/slice_info.config, finds the <plate> with the matching index, returns its curr_bed_type. When plate_id is None it returns the first plate's value (matches the archive-level capture convention). PrintQueueItemResponse gains a bed_type: str | None field; _enrich_response populates it from archive.bed_type / library_file.file_metadata["bed_type"] as the file-level default, then overrides per-plate via the new helper when item.plate_id is set. This matters because archive.bed_type is captured at ingest as the FIRST plate's value only (see services/archive.py:235) — a 40-plate 3MF mixing PEI + Engineering returns "PEI" for every plate at the archive level, even though the user's plate 17 actually needs Engineering. The per-plate override re-reads the 3MF and returns the truth. /archives/{id}/plates (and the library-file equivalent) now include bed_type in each plate object so the PrintModal's plate selector can render the badge inline. Frontend: queue card meta row gains a bed badge after filament weight — uses the existing getBedTypeInfo(bed_type) helper from utils/bedType.ts (the same one the archive card uses, so all 11 canonical bed labels + icons are covered including the BambuStudio / OrcaSlicer spelling drift). PrintModal's per-plate PlateSelector shows the bed badge under each plate's filament line; the modal header carries a bed badge for the selected (or sole) plate, surfaced before the user hits Schedule. PlateInfo + PlateMetadata types both get an optional bed_type field. No new i18n keys needed — getBedTypeInfo returns the canonical English plate name as the human label, matching the archive card's existing convention. Tests: 8 new unit cases in test_threemf_tools.py::TestExtractBedTypeFrom3mf pin the helper (single-plate, multi-plate per-plate, no-plate-id defaults to first, unknown-plate-id → None, plate-without-bed-type → None (no fall-through to another plate's value), missing slice_info, invalid file, whitespace trim). Full backend suite green (3848/3848); frontend build clean; ESLint clean; vitest on touched pages 81/81; i18n parity 5092 leaves × 11 locales green.

Added

• Print Log page: per-row failure-cause classification (#1687 part 4, reported by IndividualGhost1905) — Reporter clarified after part 1 shipped that what he actually wanted for point 2 was failure-cause grouping on the log (spaghetti, jam, bed-adhesion, etc.), not the archive tags I'd pointed him at. Archive tags describe the model (home decor, toys); the log row needs to describe what went wrong on a single print event. Different surface, different lifetime. What was already there: PrintLogEntry.failure_reason: String(100) already exists, gets mirrored from archive.failure_reason when the user edits the archive (see archives.py:1421 for the mirror that ships with #1444), and the Failure Analysis widget already groups by it. So the storage and the aggregation were both done — the only gaps were (a) the Print Log table couldn't render the value because the GET serialiser silently dropped it from PrintLogEntrySchema, and (b) orphan log entries (failures with no archive — dispatch errors, aborts before archive creation, manual entries) had no edit path at all because the Archive Edit modal can't reach them. Fix: four pieces. (1) print_log.py GET endpoint now includes failure_reason (and archive_id, created_by_id) in the serialised response — pre-fix it was silently None in every response even when the column was populated. Regression guard added. (2) New PATCH /print-log/{entry_id} endpoint accepting {failure_reason, status}, gated on require_ownership_permission(ARCHIVES_UPDATE_ALL, ARCHIVES_UPDATE_OWN) — same ownership shape as the per-row delete that already shipped. Backend validates failure_reason against the same canonical vocabulary the Archive Edit modal uses (11 enumerated keys + empty-string-clears + the other catch-all); unknown values return 400 rather than getting stored as raw garbage (the i18n layer renders the value as a key, so an unrecognised one would surface as a literal string in the UI). Status validated against the 5-value {completed, failed, stopped, cancelled, skipped} set. Empty-string failure_reason stores back as NULL so the column's nullable=True intent is preserved end-to-end. (3) FAILURE_REASON_KEYS constant moved to an export from EditArchiveModal.tsx so the new editor reuses the exact same vocabulary as the archive editor — backend and frontend stay in lockstep. (4) Frontend: pencil icon added beside the existing trash icon on every Print Log row, gated on archives:update_own/archives:update_all. Click opens a compact two-field modal (status + failure reason dropdowns). Save invalidates both print-log and archives-stats query keys so the Failure Analysis widget reflects the re-classification on the same response cycle. Failure reason is also rendered as a sub-label under the status badge in the table, mirroring the per-archive PrintLogTable.tsx convention so the two views agree. i18n: 10 new keys (editEntryTitle, editEntryDescription, entryUpdated, entryUpdateFailed, archives.permission.noEdit, plus a 5-key statuses block) translated across all 11 locales — no English fallbacks per feedback_translate_dont_fallback. Tests: 8 new backend integration cases — GET surfaces failure_reason (regression guard for the silent-drop bug), PATCH sets / clears / rejects unknown failure_reason, PATCH updates status, PATCH rejects unknown status, PATCH returns 404 on missing ID, PATCH works on orphan entries (archive_id IS NULL) — the actual reason this endpoint exists. Full backend suite 5843/5843 green; ruff clean. Frontend vitest 2108/2108 green; ESLint + build clean. i18n parity check 5110 leaves × 11 locales green.
• Print Log page: per-row delete (#1687 part 1, reported by IndividualGhost1905) — Reporter noted that the existing "Also remove this print from Quick Stats" toggle on archive delete is one-shot: if you tick "keep stats" at delete time, there was no later way to drop the row from /stats; and rows that aren't tied to an archive (errors, aborts, manual entries) had no delete affordance at all. Fix: every row in the Archives → Print Log table now has a trash icon next to the filament cell, gated on archives:delete_own (own rows) or archives:delete_all (any row), matching the archive-delete permission shape. Click → confirm modal → row is gone, and because /archives/stats aggregates over PrintLogEntry the filament / time / cost contribution drops out of Quick Stats in the same response cycle. The matching archive (if any) is untouched — the log row is a sibling, not a child. Backend: new DELETE /print-log/{entry_id} mirrors delete_archive's ownership flow via require_ownership_permission(ARCHIVES_DELETE_ALL, ARCHIVES_DELETE_OWN); owners can drop their own rows, admins can drop any row, missing IDs return 404 rather than 200-silently. Frontend: new deletePrintLogEntry API helper, per-row mutation that invalidates both print-log and archives-stats query keys so the totals re-render without a manual refresh. i18n: 4 new keys (deleteEntryTitle, deleteEntryConfirm, entryDeleted, entryDeleteFailed) translated across all 11 locales (de / en / es / fr / it / ja / ko / pt-BR / tr / zh-CN / zh-TW). Tests: 3 backend integration cases — delete drops the row from /stats while keeping the linked archive listed, missing ID returns 404, delete-one does not touch siblings (regression guard against an accidental delete(PrintLogEntry) without a where). Frontend ArchivesPage / PrintLogModal vitests stay green (31 / 31). i18n parity green (5099 leaves × 11 locales). Issue #1687 also asks for per-row tagging (already covered by EditArchiveModal's tags field) and per-row filament-usage-history edits (deferred — see the issue thread for the reasoning).

Fixed

• Filament Override "Original" label shows base type + generic color instead of the sliced sub-brand + actual color (#1718, reported by SamNuttall) — The Print Queue's filament-override panel rendered every "Original" row as {type} ({colorName}) — just the raw 3MF <filament type="..."> attribute, which is always the base material ("PLA", "PETG-HF") — plus the generic color-bucket name from getColorName(hex). A model sliced with "Bambu PLA Matte Charcoal" therefore showed up as "PLA (Black)" in the dropdown's original-filament option, and the schedule dialog gave no way to confirm the user was actually overriding what they thought they were. The 3MF DOES carry the Bambu SKU (tray_info_idx, e.g. GFA01) on each <filament> element — backend/app/api/routes/archives.py:3634/3665 already returns it in the /archives/{id}/filament-requirements response — but FilamentReqsData at frontend/src/components/PrintModal/types.ts:178 didn't carry the field, so FilamentOverride.tsx couldn't see it. The resolution path was also already in place: _BUILTIN_FILAMENT_NAMES at backend/app/api/routes/cloud.py:568 maps Bambu factory SKUs (GFA01 → "Bambu PLA Matte"), exposed as /cloud/builtin-filaments; /cloud/filament-id-map returns the same shape for user custom presets (P* prefix). KProfilesView.tsx:791 already merges those two for its own labels. Fix: add tray_info_idx?: string to the FilamentReqsData.filaments type. FilamentOverride now loads both maps via useQuery(['builtin-filaments']) + useQuery(['filament-id-map']) (both shared caches the rest of the app already populates, staleTime: 5 min) and merges them into a single idx → name lookup — user cloud preset names win over the builtin entries for the same id (the user-authored label is more specific). Both the dropdown's "original" placeholder option AND the swatch tooltip use the resolved name; the raw req.type stays as the fallback when the SKU is unknown to both sources so unknown ids degrade to today's behaviour instead of rendering blank. Color side note: Bambu Studio's specific color names ("Charcoal") live in their cloud catalog, not in the 3MF — the file carries only the hex — so Bambuddy still renders the color from getColorName(hex). "Bambu PLA Matte (Black)" is the realistic best we can do; user-readable sub-brand IS now exposed. Color disambiguation (round 2): the sub-brand half above is necessary but not sufficient — getColorName(hex) resolved through /api/inventory/colors/map, which collapses every catalog entry sharing a hex to a single name via "Bambu Lab > is_default > first" priority. Hex #000000 has 9 Bambu Lab catalog entries (Black for 8 materials, Charcoal for PLA Matte) all at the same priority, so "Black" — first encountered — wins the race and "Charcoal" is dropped before the frontend ever sees it. A new endpoint GET /api/inventory/colors/by-material?hex=X&material=Y (backend/app/api/routes/inventory.py:get_color_by_material) preserves the material context: same case-insensitive hex match as /colors/map, then a material filter on top. When no entry matches the requested material it falls back to the same priority order as /colors/map, so callers without a material hint (or with an unknown one) get exactly the existing answer — no regression for the flat-map consumers (PrintersPage, InventoryPage). FilamentOverride.tsx derives a material hint from the resolved sub-brand by stripping the leading brand token ("Bambu PLA Matte" → "PLA Matte", "PolyLite ABS" → "ABS"), dispatches one useQuery per slot via useQueries keyed on (hex, material), and uses data.color_name || getColorName(hex) so a slow query never blanks out the placeholder. Five new tests in test_color_catalog_extras.py pin: same hex + different material returns the correctly-paired name; unknown material falls back to priority order; missing hex returns color_name=null (no 404); mixed-case input on both sides matches; invalid hex (<6 chars) returns null without crashing. Three new vitest cases pin: PLA Matte Charcoal scenario lands "Bambu PLA Matte (Charcoal)", per-slot disambiguation (regression guard so a Matte slot doesn't adopt a Basic slot's answer when both share a hex), null lookup falls back to getColorName(hex). Tests overall: 20 FilamentOverride.test.tsx cases green; 12 test_color_catalog_extras.py integration cases green; combined PrintModal + FilamentOverride + FilamentMapping suite 79/79 green. Same fix applies to printer-mode FilamentMapping (round 3): the schedule modal's "Specific Printer" branch renders FilamentMapping instead of FilamentOverride and was reading the same raw fields (item.type + generic getColorName(item.color)) for the required-side row and the colour swatch tooltip — so a Charcoal slice opened against a specific printer still showed "Required: PLA - Black" while the model-mode branch already read "Bambu PLA Matte - Charcoal" against the same 3MF (caught when Sam's Specific-Printer screenshot still showed the old text after round 2 shipped). Extracted the three-query resolution machinery from FilamentOverride.tsx into a shared hook useFilamentLabels in frontend/src/components/PrintModal/useFilamentLabels.ts so the two panels can't drift on label content; FilamentOverride and FilamentMapping now both call useFilamentLabels(filamentReqs?.filaments) and read positional { resolvedName, colorLabel } per slot. The hook also exports the extractMaterialHint helper so backend material-hint test parity is mechanical (one source of truth for "strip the leading brand token"). FilamentMapping's required-side type label now reads {resolvedName} instead of raw {item.type}, and the colour swatch tooltip reads Required: {resolvedName} - {colorLabel} instead of Required: {item.type} - getColorName(item.color). New vitest case renders sub-brand + material-disambiguated colour on the required side (#1718) mirrors the FilamentOverride Charcoal scenario against FilamentMapping (msw stubs for builtin-filaments + by-material). Existing FTS dropdown-filter / force-color-match cases stay green. Hook itself gets direct unit coverage in a new useFilamentLabels.test.tsx (11 cases — extractMaterialHint corner cases, SKU resolution, cloud-over-builtin precedence, fallbacks, positional alignment across slots with same hex but different materials, and the enabled: !!color query gate). The earlier "case-insensitive on both inputs" backend test (in test_color_catalog_extras.py) is rewritten to actually seed an upper-case stored hex and query it with lower-case input — the original version only checked invalid-hex returns null, which is the wrong assertion for the test name. Combined PrintModal + FilamentOverride + FilamentMapping + useFilamentLabels + useFilamentMapping suite 144/144 green; eslint clean, build clean. What this fix can NOT recover: for hexes the catalog has no entry for (third-party filament manually loaded, etc.), the color label degrades to the existing HSL-bucket name from getColorName(hex) — still strictly better than blank, but Bambu's specific color names only live in the seeded catalog. Frontend + backend; no migration, no new i18n keys; ruff clean, eslint clean, frontend build clean, i18n parity unchanged.
• Force-color-match checkbox missing when scheduling against a specific printer (#1717, reported by SamNuttall) — The Print Queue's schedule dialog hides the per-slot "Force color match" checkbox in the "Specific printer" path. Picking "Any A1" (model-mode dispatch) renders FilamentOverride which carries the checkbox, but picking a single printer renders FilamentMapping instead — a separate component that had no force-match UI. The dispatcher in print_scheduler.py:535 already honours force_color_match regardless of how the queue item was created (the flag survives end-to-end on the filament_overrides payload buildFilamentOverridesArray constructs in PrintModal/index.tsx:613), so this was a pure UI gap — printer-mode users could not request the safety guard from the modal even though the backend would have respected it. Fix: FilamentMapping accepts new optional forceColorMatch + onForceColorMatchChange props mirroring FilamentOverride's shape; it renders the same <Palette>-iconed checkbox under each filament row when a handler is provided. PrintModal/index.tsx:1100 passes the existing forceColorMatch state and a setForceColorMatch setter through — same state object both modes write into, so toggling between modes preserves what the user selected. No new i18n keys (the existing printModal.forceColorMatch key already ships in all 11 locales). The checkbox is suppressed when no handler is wired (avoids dead UI in callers that don't manage the flag). Tests: new renders the per-slot force-color-match checkbox in printer mode (#1717) case clicks the checkbox and asserts onForceColorMatchChange(slotId, true) fires; companion omits the force-color-match checkbox when no handler is provided case pins the absent-handler branch. Existing FTS dropdown-filter tests stay green. FilamentMapping.test.tsx 4/4 green; combined PrintModal + FilamentOverride + FilamentMapping suite 73/73 green; eslint clean; frontend build clean; i18n parity 5120 leaves × 11 locales green.
• In-app updater fails when DATA_DIR is on a separate mount from the install (#1715, reported by francescocozzi) — Native installs that follow the systemd template WorkingDirectory=/opt/bambuddy with Environment="DATA_DIR=/srv/bambuddy/data" (or any layout where DATA_DIR is not a subdirectory of the install path) couldn't apply in-app updates. Every git step in _perform_update (remote get-url, remote set-url, fetch, reset --hard) used cwd=settings.base_dir, and safe.directory was pointed at base_dir too. On the standard install (DATA_DIR=INSTALL_PATH/data) this happened to work by accident — git walks up from a subdirectory of the repo to find .git — but on a separate-mount layout the data dir is not under the install, the walk-up has nowhere to go, and every operation returns "fatal: not a git repository." Even on the standard install safe.directory={base_dir} was wrong (it must equal the repo root git discovers, not the data dir), surfacing on hardened systemd units as "fatal: detected dubious ownership." Fix: route every git subprocess in _perform_update and _origin_points_at_repo through cwd=settings.app_dir (the working tree), and set safe.directory={app_dir} to match. app_dir is now resolved once at the top of _perform_update instead of lazily re-resolved before the pip step. The base_dir parameter on _origin_points_at_repo is renamed to app_dir so the signature documents the contract. The pip-install step keeps cwd=app_dir (unchanged — that step was already correct). Tests: new test_perform_update_runs_git_in_app_dir_when_data_dir_on_separate_mount integration case constructs a sibling-paths layout (tmp/opt/bambuddy + tmp/srv/bambuddy/data — the exact #1715 shape), mocks asyncio.create_subprocess_exec to capture every call's cwd, and pins (a) every git subprocess runs with cwd=app_dir, (b) the embedded safe.directory= config equals app_dir on every git call. The existing pip-cwd test stays green (pip's cwd was already app_dir). Existing SSH-origin-preserve + origin-rewrite + reset-target tests stay green (they don't assert on git cwd). Full test_updates_api.py 21/21 green; ruff clean. Credit: root cause + fix shape from francescocozzi via PR #1716 (couldn't be merged as-is — that branch had drifted off an older dev and pulled in unrelated upstream commits including a version regression).
• SliceModal preset-lookup precedence + cross-tier dedup + signed-out banner (#1712, reported by IndividualGhost1905) — After the Orca Cloud integration shipped (2026-06-04), every user — including Bambu-Cloud-only / Bambu-Studio-preferred users — got Orca Cloud as the top tier across the SliceModal preset picker, the per-preset auto-pick scoring, the dropdown's optgroup rendering, the AMS slot picker's filament sort, and the backend dedup precedence. A Bambu-Cloud / X1C user reported seeing his Bambu Cloud profiles disappear from auto-pick because Orca Cloud's empty tier shadowed them. The cross-tier dedup (introduced with #1150 and inherited as-is by the Orca change) compounded the problem: a name that existed in multiple tiers showed in only ONE group, so a user with a local-imported and Orca-synced "Bambu PLA Basic" never saw the Orca copy as a picker option — even though they curate both sources. And the cloud-status banner (CloudStatusBanner) nagged signed-out users with a permanent "Sign in to Orca Cloud (Profiles → Orca Cloud) to see your Orca presets" at the top of every SliceModal open — even after a user had explicitly logged out of Orca Cloud. The Bambu Cloud banner had the symmetric problem. Fix — order: precedence is local > orca_cloud > cloud > standard across SliceModal.tsx (SLICE_MODAL_TIER_ORDER + TIER_BONUS + dropdown tier list), ConfigureAmsSlotModal.tsx (sourceOrder), and docstrings in slicer_presets.py / schemas/slicer_presets.py / client.ts. Local imports win (the user did them on purpose), Orca Cloud comes next, Bambu Cloud, bundled fallback last. The order drives auto-pick + visual group order; it does NOT hide profiles. Fix — no dedup, full lists: _dedupe_by_name is replaced by _enrich_cloud_metadata, which returns every tier's full preset list across all three slots (printer / process / filament) — a name in local AND orca_cloud AND cloud renders in EACH of their groups so the user can pick any source. The only work the function still does is filament-metadata backfill: a Bambu Cloud filament without its own filament_type / filament_colour inherits values from a same-named local / orca_cloud / standard entry so it can still score in pickFilamentForSlot. Printer + process presets carry their metadata inline and need no enrich. Frontend code already iterates tiers in priority order and surfaces every entry — no change needed there once the backend stops filtering. Fix — banner: CloudStatusBanner now silently returns null on not_authenticated in addition to ok — applies symmetrically to both Bambu and Orca cloud banners. expired (token broke) and unreachable (network / service down) still surface — those are real breakage states a previously-signed-in user needs to see. Sign-in lives on the Profiles page; the modal doesn't need to advertise it. The slice.cloud.notAuthenticated / slice.orcaCloud.notAuthenticated i18n keys stay in the locale files (dormant) so re-enabling later doesn't need a re-translation pass. Fix — ConfigureAmsSlotModal source badges: before this change, the per-row source badge fired three branches independently — local got a green "Local" badge, builtin got an amber "Built-in" badge, and a blue "Custom" badge appeared on top of those when isUser was true. Since ALL Orca Cloud entries are marked isUser: true and Bambu Cloud user presets also get the same flag, the result was visually inconsistent: Orca Cloud rows showed only "Custom" (no source identification, no way to tell them from Bambu Cloud user presets), Bambu Cloud built-in rows had NO badge at all, and the "Custom" badge collided with the actual source. Replaced with a single source badge per row: green "Local", purple "Orca Cloud" (new), bambu-blue "Bambu Cloud" (new), amber "Built-in". One badge per row; one colour per source; the isUser distinction within the Bambu Cloud tier is dropped (the preset name itself carries the "is this user-authored" signal). Same change in both render blocks (the filament-list code is duplicated in the modal — kept the duplication local rather than refactoring out a helper component in this PR to keep the diff tight). i18n: 2 new keys (configureAmsSlot.orcaCloud, configureAmsSlot.bambuCloud) translated to all 11 locales — both are brand names, already on the per-locale IDENTICAL_TO_EN_ALLOWED lists so the parity check is satisfied without per-locale variants. The dormant configureAmsSlot.custom key stays in the locale files. Tests: TestEnrichCloudMetadata replaces TestDedupeByName (5 cases): regression guard pinning that a name in all four tiers appears in EACH (not just local), tier order preserved within a tier, Bambu Cloud filament metadata backfilled from local, backfill falls through to orca / standard when local doesn't carry the name, backfill does NOT overwrite Bambu Cloud's own metadata when present. The "renders a sign-in banner when cloud_status is not_authenticated" case flipped to assert no banner appears, with the test name updated to call out the #1712 reason. Backend test_slicer_presets.py 47/47 green; SliceModal.test.tsx 34/34 green; ConfigureAmsSlotModal.test.tsx 24/24 green; ruff clean; frontend build clean; i18n parity 5120 leaves × 11 locales green.
• Telegram (and other image-bearing) finish notification on a reprint-from-archive showed the original print's finish photo instead of the new run's (#1707, reported by kycrna) — P2S user reprinted an archived job and observed the Telegram notification arriving with the photo of the original print (white box) attached to the completion message for the new run (black box). Root cause: reprints reuse the source archive row — register_expected_print stores the source archive_id in _expected_prints, and the on-print-start expected-archive promotion branch at main.py:2207-2245 updates the row's status / started_at / printer_id / subtask_id but never reset archive.timelapse_path. Two failure modes cascaded from the stale path: (a) _scan_for_timelapse_with_retries early-returns at main.py:3062 with if archive.timelapse_path: return — the reprint's new timelapse MP4 sitting on the printer's SD card was never downloaded, the archive's timelapse_path kept pointing at the original run's local file; (b) _capture_finish_photo_from_timelapse polls archive.timelapse_path and immediately found the original video, extracted ITS last frame as finish_<fresh-timestamp>_<uuid>.jpg, and handed those bytes to _background_notifications as image_data — which then went out to Telegram via the sendPhoto path. The filename was new (so log lines and the archive's photos list looked correct), but the pixels were the original run's finish frame. Surface was specific to the timelapse-prefer path: with data.timelapse_was_active true and no external camera, prefer_timelapse_source was True, which is the exact configuration on P2S with timelapse-on for both runs. External-camera, buffered-frame, and fresh-RTSP fallback paths grab the current camera frame, so users on those paths saw correct photos and the bug stayed hidden. Fix: at expected-archive promotion, capture and clear archive.timelapse_path to None before the commit, and os.unlink the stale on-disk video so reprints don't accumulate orphaned MP4s in the archive directory. Photos list is left alone — accumulating one finish photo per run across the archive's lifetime is the right behaviour. The unlink is wrapped in OSError-catching best-effort logging so a missing file (manual delete, archive purge, container rebuild with bind-mount drift) doesn't break promotion. The clear-and-unlink runs unconditionally when timelapse_path is set, so even if a user has been reprinting under the buggy build for months, the next reprint self-heals. Tests: 3 new cases in test_reprint_clears_stale_timelapse.py exercise the full on_print_start callback through the expected-archive branch — happy path (path cleared + file unlinked), no-prior-timelapse (no-op, promotion still succeeds), missing-stale-file (best-effort unlink doesn't raise). Full test_print_start_expected_promotion.py + test_print_start_assigns_printer_id_to_vp_archive.py suite (28/28) stays green; ruff clean.
• Connection diagnostic no longer flags external_storage: fail on A1 / A1 Mini, which physically have no MicroSD slot (#1703, reported by MartinNYHC) — Bug report from an A1 user complained that BambuStudio and OrcaSlicer don't have an "external storage" tick box (correct — there's nothing to toggle, the A1 series ships without a SD card slot at all) while the Bambuddy support bundle simultaneously reported external_storage: fail in the printer's connection diagnostic. The two together left the user thinking Bambuddy was wrong about a setting their hardware doesn't have. Root cause: the external_storage check at services/printer_diagnostic.py:179-189 reads state.store_to_sdcard, which is parsed from MQTT home_flag bit 11. On A1 and A1 Mini that bit is never set (no hardware slot, no firmware-side toggle, no slicer-side equivalent), so the value pushes as False and the check fell through to fail instead of skip. Fix: new NO_EXTERNAL_STORAGE_MODELS frozenset in utils/printer_models.py enumerating A1, A1 Mini, and their internal codes (N1, N2S, A04, A11, A12), plus a has_external_storage(model) helper that returns False for those and True for everything else (unknown models default to True so the check stays active for any future Bambu model that ships with a slot — new no-slot models must be added to the set explicitly). The diagnostic now short-circuits to skip before reading store_to_sdcard when printer.model is in the set. What this does NOT change: X1 / X1E / P1S / P1P / P2S / H2D / H2D Pro / H2C / H2S / X2D continue to evaluate store_to_sdcard exactly as before — the home-flag-bit-off → fail path is still the right signal for them. The companion FTP-upload-timeout symptom in the same bug report (ftp code 28 from BambuStudio when sending to the proxy VP) is a separate Docker-bridge-mode networking constraint, not addressed by this change. Tests: 8 new cases — TestHasExternalStorage (5 cases) pins the model list, internal-code aliasing, case/whitespace normalisation, unknown-defaults-true, and null/empty-defaults-true; TestExternalStorageCheck gains test_skips_on_a1_no_external_storage_slot, test_skips_on_a1_mini_no_external_storage_slot, and test_still_fails_on_x1c_when_toggle_off (regression guard that the model-aware skip doesn't accidentally silence the genuine signal on slotted models). Full test_printer_models.py + test_printer_diagnostic.py + archives integration suite green (172/172); ruff clean.
• AMS slot card surfaced the previous spool's preset name after RFID auto-assigned a new spool (reported with H2D-1 / AMS-B3 / PLA-CF showing as "Bambu PLA Silk+") — Reporter inserted a fresh Bambu PLA-CF spool into AMS-B3, RFID identified it correctly, but the slot card kept showing "Bambu PLA Silk+" (the name from a PLA Silk+ spool that had occupied the slot back in March). Confirmed in the live data: slot_preset_mappings row for (printer_id=1, ams_id=1, tray_id=2) was preset_id=GFSA06_09, preset_name='Bambu PLA Silk+', updated_at=2026-03-15 — three months stale. Root cause: slot_preset_mappings.preset_name is first in the PrintersPage display chain (PrintersPage.tsx:3624) and overrides the spool's own slicer_filament_name plus the cloud catalog cloudInfo.name. The internal-mode manual-assign path (inventory.apply_spool_to_slot_via_mqtt) kept this row in sync, but the internal-mode RFID auto-assign path (spool_tag_matcher.auto_assign_spool) skipped it entirely. The Spoolman-mode sync path (main.auto_sync_spoolman_ams_trays) also skipped it — same bug shape, latent for Spoolman users who'd never manually configured a slot preset, active for those who had. Fix — three writers in lockstep via one shared helper. New backend/app/services/slot_preset_writer.py exposes a primitive upsert_slot_preset plus two convenience wrappers: upsert_slot_preset_for_spool for internal Spool ORM objects (local-preset numeric ids → local_{n}, cloud ids run through filament_id_to_setting_id) and upsert_slot_preset_for_spoolman_spool for Spoolman dicts (filament.name → preset_name, tray_info_idx → preset_id). All three call sites — the manual-assign block in inventory.py:396-438, the RFID auto-assign tail in spool_tag_matcher.py:auto_assign_spool, and the per-tray-sync branch in main.py:auto_sync_spoolman_ams_trays — now go through the helper. Self-heal: existing stale rows from past spool swaps get rewritten the next time a fresh spool is detected on the same slot. No migration script needed. What this also covers per feedback_inventory_modes_parity: the bug shape exists in both internal and Spoolman modes, so the patch ships fixes for both inventory paths in the same drop — a Spoolman user with a manually-configured slot preset would have seen the same stale-name behavior after every RFID swap until the row was overwritten through Configure Slot. Tests: new test_slot_preset_writer.py (6 cases) pins the helper contracts — no-op on empty preset_id, upsert idempotency, Spoolman filament.name → preset_name, fallback to material → tray_sub_brands → tray_type, stale-row overwrite from the Spoolman path, skip when tray_info_idx is unknown. New test_spool_tag_matcher.py cases (3) pin the internal RFID-auto-assign path — stale-row overwrite (the exact reporter shape: PLA Silk+ → PLA-CF), fresh insert when no row exists, local_{n} formatting for numeric local-preset ids. Total touched-area suite 69/69 green; broader related suite (inventory + spoolman + spool_tag + auto_sync) 767/767 green; ruff clean.
• Stats page Failure Analysis widget rendered raw camelCase keys instead of translated reasons (#1687 follow-up, reported by IndividualGhost1905) — After #1687 part 4 shipped the per-row Print Log editor, the reporter classified a couple of failed runs and saw "filamentRunout" / "cloggedNozzle" (the literal camelCase keys) appear under Statistics → Failure Analysis → Top Failure Reasons, while the same rows rendered correctly as "Filament runout" / "Clogged nozzle" on the Print Log table. Surfaced an inconsistency I introduced when shipping the new editor: the new Print Log row editor saves the camelCase key (filamentRunout) which is what the new backend PATCH validates against, but the older EditArchiveModal was still saving the localised label ("Filament runout") as the value — two formats landing in the same PrintLogEntry.failure_reason column from two different UI surfaces. The Failure Analysis widget at frontend/src/pages/StatsPage.tsx:817 and the per-archive run history sub-table at frontend/src/components/PrintLogTable.tsx:81 both rendered the raw column value without running it through i18n, so the new key-form values surfaced as literal keys. Fix — three sites in one drop: (1) StatsPage.tsx and (2) PrintLogTable.tsx now wrap the value in t('editArchive.failureReasons.${reason}', { defaultValue: reason }) — same pattern already used at ArchivesPage.tsx:3874 for the Print Log table. The defaultValue fallback keeps legacy translated-text rows rendering as-is, no regression. (3) EditArchiveModal.tsx now saves the camelCase key (<option value={reasonKey}>) instead of the localised label, matching the new editor's wire format. On modal open, a reverse-lookup against the current locale resolves any legacy translated-text value back to its key so the dropdown pre-selects the right option — every save thereafter converts that row forward to the key format, so the data set self-heals over time without a migration script. Added htmlFor/id linkage to the failure-reason <label>/<select> pair as a side benefit (lets getByLabelText in tests reach the control, plus a small a11y improvement). What this also fixes invisibly: German / Japanese / Turkish users who classified rows under one UI language and then switched languages would have seen their historical buckets fragment in the Failure Analysis widget (each translation = its own group). With keys as the storage format, language switch no longer reclassifies anything. Tests: 5 new vitest cases — StatsPage translates camelCase failure-reason keys and renders legacy translated-text failure reasons unchanged; EditArchiveModal preselects the option when the stored value is already a camelCase key, reverse-looks-up a legacy translated value back to its key, and sends the camelCase key on save, not the translated label; PrintLogModal translates camelCase failure_reason keys. The existing shows failure_reason under failed runs case (which checks legacy text path) keeps passing under the defaultValue fallback. Full vitest 58 / 58 across touched files. ESLint clean; frontend build clean (vite 9.61s); i18n parity 5118 leaves × 11 locales green (no new keys — reuses editArchive.failureReasons.*).
• System page boot time was rendered with a doubled timezone offset (#1690 follow-up, reported by IndividualGhost1905) — After the original #1690 fix landed in 0.2.4.6, the reporter on UTC+3 (Turkey) confirmed uptime was correct but boot time displayed +3 hours ahead of reality. Root cause: backend/app/api/routes/system.py built boot_time as a NAIVE LOCAL datetime via datetime.fromtimestamp(psutil.Process(1).create_time()) and serialised it with .isoformat(), which emits no timezone marker (e.g. "2026-06-09T11:22:05"). The frontend's parseUTCDate() helper at frontend/src/utils/date.ts:206 is documented to append 'Z' when no tz marker is present, treating the string as UTC, then toLocaleString converts UTC → local — applying the local offset on top of an already-local timestamp. Uptime was unaffected because it's computed entirely backend-side as datetime.now() - boot_time, two naive-local values whose delta is correct regardless of the missing tz info. Fix: make both boot_time and the uptime anchor tz-aware UTC — datetime.fromtimestamp(ts, tz=timezone.utc) on the main path and the psutil.boot_time() fallback, and datetime.now(timezone.utc) in the uptime subtraction. isoformat() then emits "+00:00" and the frontend's parseUTCDate uses the marker as-is. Same naive-datetime pattern surfaced in two adjacent generated_at fields — the storage-usage cache snapshot in system.py and the support bundle root in support.py. Neither is rendered as a wall-clock timestamp in the frontend today, but both now emit tz-aware UTC for consistency so any future surface that does render them won't recreate this bug. Tests: new test_boot_time_isoformat_carries_utc_marker regression case asserts the boot_time string ends in +00:00 (or Z) — without that marker the frontend double-converts, which is exactly the reporter's symptom. Existing test_boot_time_uses_pid1_create_time and test_boot_time_falls_back_to_psutil_boot_time_on_pid1_failure still pass under the tz-aware values because 1700345600 is 2023-11-18T20:53:20+00:00 UTC, so the date-prefix assertion is unaffected. Full system API suite 21/21 green; support API 72/72 green; ruff clean.
• A1 / A1 Mini internal-code map was swapped in PRINTER_MODEL_ID_MAP (surfaced while scoping A2L support, #1684) — backend/app/utils/printer_models.py mapped N1 → "A1" and N2S → "A1 Mini", but every other registry that names these codes — firmware_check.py (N2S → "a1"), virtual_printer/manager.py (both the model map and the serial-prefix map: N2S → "03900A" is the A1's 039 prefix, N1 → "03000A" is the A1 Mini's 030), printer_manager.py A1_MODELS — consistently uses the opposite (correct) direction. Any path that resolved an A1-family printer by internal code rather than serial prefix would silently misclassify. Fix: swap PRINTER_MODEL_ID_MAP to N1 → "A1 Mini", N2S → "A1"; the matching comment in LINEAR_RAIL_MODELS was also wrong and got the same swap (the frozenset's contents don't change — both codes were already in it — so this is cosmetic, but kept the file self-consistent). New regression test class TestA1SeriesModelIds pins both directions so a future re-flip fails loudly. Functional impact in practice is small (most A1 detection runs off the serial prefix), but the inconsistency was a footgun for any future caller that trusted normalize_printer_model_id. Backend printer-model suite 46 / 46 green; ruff clean.
• PostgreSQL restore from a SQLite backup no longer deadlocks against the print scheduler (reproduced 2026-06-09 restoring a native install's backup into a fresh Docker+Postgres deploy) — Reporter (Maziggy) backed up the native install, brought up the new Docker image against an external Postgres, hit Restore in Settings → Backup. ~2 seconds in, the restore aborted with asyncpg.exceptions.DeadlockDetectedError: Process X waits for AccessExclusiveLock on relation 109940; Process Y waits for RowExclusiveLock on relation 110182. Root cause: the existing close_all_connections() step before the DB swap only disposes the SQLAlchemy engine's connection POOL — the asyncio tasks that USE the engine keep running. The print_scheduler.run() loop (30 s cadence) and smart_plug_manager._snapshot_loop() (30 s cadence) wake up after the dispose, call async_session(), lazily reopen a pool connection, and start a normal transaction that grabs RowExclusiveLock on print_queue / smart_plug_energy_snapshots. The restore's DROP TABLE IF EXISTS public.<tbl> CASCADE pass in _import_sqlite_to_postgres needs AccessExclusiveLock on every public table — AB/BA lock-order conflict, classic Postgres deadlock, restore transaction rolled back. The log confirms: 13:44:53,669 restore begins → 13:44:53,680 print_scheduler fires queue check → 13:44:55,607 smart_plug_manager fires snapshot → 13:44:55,607 deadlock detected. The existing code already paused virtual_printer_manager before restore for file-lock reasons; the other timer-based DB writers were missed. Fix — two layers. (1) Before close_all_connections(), pause the four most active timer-based DB writers via their existing stop affordances: print_scheduler.stop(), smart_plug_manager.stop_scheduler(), notification_service.stop_digest_scheduler(), await background_dispatch.stop(). Then await asyncio.sleep(1.0) to let in-flight loop iterations commit and release their sessions before the engine pool gets disposed. We don't restart the services on success because the restore handler already tells the user to restart Bambuddy to pick up the new DB. (2) Belt-and-braces inside _import_sqlite_to_postgres: prepend SET LOCAL lock_timeout = '10s' to the begin-block before the DROP TABLE CASCADE pass, so any residual writer that slips through the pause window (per-printer MQTT clients writing reactively to state changes, the hourly AMS history recorder firing inside the restore window, etc.) surfaces a fast lock_timeout error instead of producing a fresh deadlock or hanging the restore for 30+ seconds. SET LOCAL is transaction-scoped so the global default applies to every other DB caller. Scope clarification: there are ~12 background services started at lifespan startup; the four paused here are the ones with the tightest cadences. Slower-cadence services (github_backup_service, local_backup_service, library_trash_service, archive_purge_service, AMS history, runtime tracking, SpoolBuddy watchdog, camera cleanup) all fire on hour-or-longer intervals and are statistically very unlikely to land inside a few-second restore window; the lock_timeout layer catches them if they do. Tests: test_restore_sqlite_wal_safety.py and test_settings_api.py integration suites (53 tests) stay green on the edited handler; ruff clean; runtime smoke (from backend.app.services.X import Y + hasattr + iscoroutinefunction check) confirms all four stop signatures match the patch's sync/async mix.
• Configure Slot now keeps the active K-profile on reopen for assigned-but-unconfigured slots (#1689 follow-up, reported and patched by Spionkiller01) — After the original #1689 fix shipped, Spionkiller01 found a residual case: on a slot that's physically loaded but unconfigured (filament inserted, but the printer hasn't bound a preset yet — tray_type="", tray_info_idx="", no slot_preset_mappings row), the first open of Configure Slot showed the right K-profile, but closing it with the X and reopening it dropped back to "default 0.020". Clicking "Configure slot" (Apply) once persisted it, but the user shouldn't have to. Root cause: the original #1689 cali_idx safety net was unreachable on this code path. matchingKProfiles in ConfigureAmsSlotModal.tsx:751 early-returned [] when selectedPresetInfo was null — and selectedPresetInfo resolves to null exactly when there's no resolvable slot preset (unconfigured slot, no mapping row). The "always include the slot's currently-active K-profile by cali_idx" branch lives past the main name+id matcher, so it never ran from the no-preset path. On first open a freshly-cached preset briefly let the safety net trigger; on reopen the live slot state had no preset, returned [], the auto-select effect saw no candidates, the modal fell back to default 0.020. Fix (verbatim from Spionkiller01's H2C-tested diff, with the existing extruder guard): split the early return into two — still short-circuit on missing kprofilesData, but when selectedPresetInfo is null and slotInfo.caliIdx > 0, find the active profile by slot_id === activeIdx (extruder-matched when known) and return it as a single-item list. The auto-select effect downstream then pre-selects it on reopen with no extra change. Strictly additive: with a resolvable preset present the existing matcher runs untouched; with caliIdx === 0 || null the function still returns [] (no unrelated profiles leak in). Tests: new vitest case surfaces the slot's active K-profile when no preset is resolvable (#1689 follow-up) exercises the path with trayType='', no savedPresetId, and caliIdx=6 against a K-profile fixture at slot_id=6 — asserts the dropdown surfaces it. Verified the test fails without the patch (stash → run filter → fail; pop → run → pass). The existing caliIdx === 0 guard test continues to pass under the new branch. Full ConfigureAmsSlotModal vitest 24/24 green. Credit: Spionkiller01 for spotting the residual edge case after merge, producing the diff, and testing live on an H2C — Co-Authored-By on the commit.
• K-profile matching now prefers filament_id over parsed names — surfaces custom profiles in the spool form AND fixes Configure Slot showing "default 0.020" for an actively-bound K-profile (#1688 + #1689, both reported and diagnosed by Spionkiller01 with concrete H2C testing; #1689 also reported by IndividualGhost1905) — Two related symptoms on different UI surfaces, same root cause. #1688: spool form's PA-profile suggester (frontend/src/components/spool-form/PAProfileSection.tsx via isMatchingCalibration in spool-form/utils.ts) only matched K-profiles by parsing the profile name for material/brand/variant. Spools already store slicer_filament (the slicer preset's id) and K-profiles already carry filament_id, but both were ignored — so a user's custom K-profile whose name doesn't agree with the slicer preset's name got silently dropped from the suggestion list even when the underlying filament_id was identical. #1689: ConfigureAmsSlotModal's K-profile filter (matchingKProfiles) ran the same name-only logic on the slot's selected preset — a spool assigned under "Generic PLA" with a custom K-profile actively bound on the printer landed in the modal as "K profile not assigned, default 0.020 will be used", while the printer-card hover-card correctly showed the active profile. The hover-card and the Configure Slot modal disagreed because they used different lookup paths; the modal's path was the one with the name-parse filter. The shared root cause: spool preset ids and K-profile filament_ids look different but are equivalent after normalisation. Spools store slicer_filament as the cloud setting_id form ("GFSG98_09" — _09 is the variant suffix, the "S" infix marks it as a setting_id); K-profiles store filament_id as the bare form ("GFG98"). Plain === doesn't match; both need normalising first. This conversion already exists in the other direction at buildFilamentOptions (filament_id → "GFS" + filament_id.slice(2) for setting_id), so the inverse toFilamentId helper isn't speculative — it's just the matching reverse. Fix — one shared helper, two surfaces: new exports in frontend/src/components/spool-form/utils.ts — toFilamentId(id) normalises both shapes by dropping the "_NN" variant suffix and stripping the "S" in "GFS" (so both "GFSG98_09" and "GFG98" yield "GFG98"); isGenericFilamentId(id) flags Bambu's generic GFx99 ids (GFL99 = generic PLA, GFG99 = generic PETG, etc.) which are shared across many physical filaments and must NOT id-match (they over-match and obscure brand-specific profiles — name fallback handles those correctly). Then: (1) isMatchingCalibration accepts a new slicer_filament?: string formData field, tries id-match first (with generic exclusion), falls through to the existing name parse — PAProfileSection already passes the full formData so no caller edit needed. (2) ConfigureAmsSlotModal.selectedPresetInfo now also resolves a filamentId (via toFilamentId(cp.setting_id) for cloud presets; toFilamentId(builtinFilamentId) for builtin; empty for local/orca paths that fall through to name match); matchingKProfiles adds the id-match check at the top of the per-profile predicate, then keeps the existing name logic, then always unshifts the slot's currently-active K-profile (by slot_id === slotInfo.caliIdx, gated on activeIdx > 0 so caliIdx=0/null doesn't leak unrelated profiles in, and extruder-matched when known) — covers the #1689 case where the spool was bound under a generic preset but the active profile lives under a different filament_id entirely. The "always include active" branch is Spionkiller01's #1689 diff verbatim, gated more tightly. SpoolBuddy coverage: both K-profile surfaces in the kiosk UI reuse the shared components — SpoolBuddyWriteTagPage renders <PAProfileSection> (auto-fixed via isMatchingCalibration), SpoolBuddyAmsPage renders <ConfigureAmsSlotModal> (auto-fixed via matchingKProfiles). No kiosk-specific edits required; the shared helpers carry the fixes through. (SpoolBuddyCalibrationPage is scale calibration, unrelated; InventorySpoolInfoCard is display-only.) What this does NOT change: spools without a slicer_filament, K-profiles without a filament_id, and generic GFx99 ids all fall through to the existing name-based matching path — strictly additive precedence, no behaviour change for the name-only cases that already worked. The new id-match never causes a miss the old code would have caught. Tests: 21 new vitest cases — isMatchingCalibration.test.ts (18 cases) pins the toFilamentId round-trip in both directions (GFSG98_09 → GFG98 and back is identity-preserving for the cloud→K-profile flow), the generic GFx99 exclusion, falsy/non-Bambu id pass-through (numeric local-preset id, Orca UUID), and the id-match-wins-over-name behaviour including the spool's reported "GFSG98_09" ↔ K-profile "GFG98" real-data scenario. ConfigureAmsSlotModal.test.tsx (3 cases) pins the modal-level behaviour: a custom K-profile name surfaces when filament_id matches (#1688 in-modal), the slot's active profile is always included even with no name/id match (#1689), and the caliIdx == 0 guard prevents unrelated profiles from leaking in via the safety net. Full frontend vitest suite: 2108 / 2108 green. ESLint clean on touched files; frontend build clean. Credit & dispatch: Spionkiller01 diagnosed both issues with concrete data (the GFSG98_09 ↔ GFG98 normalisation case is theirs), tested both patches live on an H2C, and explicitly offered to PR. Landed verbatim with adjustments (shared helper, tighter active-profile guard) and Co-Authored-By. IndividualGhost1905 also reported #1689 independently and identified its connection to #1688.
• Tabs no longer go silently zombie after the JWT expires — auth-expiry now redirects to /login on the same tab (#1698, reported by TCL987, fix patched in reporter's fork) — Reporter on X1C, Docker install, left a Bambuddy tab open past the 24 h JWT lifetime. After expiry: navigation between pages still worked, but every API request silently failed, leaving the UI looking like every list was empty. A manual refresh was needed to land on /login. Root cause: AuthContext.user stays stale after the JWT clears. When a 401 with a token-invalidating message (Token has expired, Could not validate credentials, User not found or inactive, Invalid API key, API key has expired) lands in frontend/src/api/client.ts:154-167, the handler calls setAuthToken(null) to drop the token from sessionStorage / localStorage — but AuthContext.user is a React state value that was populated once at mount via checkAuthStatus() → /auth/me, and setAuthToken(null) doesn't reach into AuthContext's React tree. ProtectedRoute (App.tsx:101) only redirects when user === null, so the protected tree keeps rendering, every subsequent request goes out with no Authorization header, the backend 401s, and the UI shows nothing. A page refresh remounts AuthProvider, checkAuthStatus() finds no token, setUser(null) fires, the redirect runs — which is what the reporter ended up doing every 24 h. The 3 other setAuthToken(null) call sites all live inside AuthContext itself and pair with setUser(null) directly, so no cross-module signal was needed for them; the client.ts:165 site was the only one missing the React-tree notification. Fix (mirrors the reporter's fork patch deec96d): after setAuthToken(null) in client.ts, dispatch a window.dispatchEvent(new CustomEvent('auth:expired')) (guarded on typeof window !== 'undefined' for SSR / test safety). AuthContext's mount useEffect adds a window.addEventListener('auth:expired', handleAuthExpired) listener whose handler calls setUser(null) after a mountedRef.current guard, and removes the listener in the effect's cleanup so unmount → remount doesn't double-bind. ProtectedRoute then sees user === null on the next render and runs <Navigate to="/login" replace /> immediately, no manual refresh needed. What this intentionally does NOT change: generic 401 Authentication required responses (without a token-invalidating message) still don't clear the token or fire the event — they're treated as transient timing issues, exactly as client.ts:155's pre-existing comment documents. So a one-off 401 from a race during login won't redirect a working session. Listener cleanup means tests / dev hot-reload don't accumulate handlers. Tests: 4 new vitest cases — client.test.ts gains "dispatches 'auth:expired' event on 401 with invalid token message" and "does not dispatch 'auth:expired' on 401 with generic auth error" (both use vi.fn() listeners on window to assert the event fires/doesn't fire). AuthContext.test.tsx gains a new auth:expired event (#1698) describe block — "clears user when an auth:expired event is dispatched" simulates the login → expiry → event → user-null flow end-to-end via setAuthToken('valid-token') (the canonical setter; writing to sessionStorage post-import wouldn't propagate to the module-level authToken variable initialised at import time), and "does not crash when the event fires after unmount" pins the mountedRef guard so the listener can't trigger a state-update-after-unmount warning. Full frontend vitest suite: 2087 / 2087 green. ESLint clean on touched files. Frontend build clean. Credit to TCL987 for diagnosing this and shipping the working fix on their fork before opening the issue.
• Filament usage no longer over-counts when printing one plate from a multi-plate 3MF (#1697, reported by volodymyr-doba) — Reporter on P1S printed a single lid (~190 g grey PETG) from gridfinity-storage-box-5x4x6.gcode.3mf (a multi-plate file with 5×box + 5×lid plates) and the spool's Usage History recorded 242 g of grey + 31 g of black — the whole file's filament total, not the dispatched plate. The print took 5 h 47 m which matches the lid alone, and the queue card correctly previewed 190 g, but the spool got debited for everything. Root cause: usage tracking parsed the 3MF without a plate filter. extract_filament_usage_from_3mf(file_path, plate_id) in backend/app/utils/threemf_tools.py already supports filtering and the queue's pre-flight capacity check at api/routes/print_queue.py:254/:286 passes item.plate_id, but the two completion-time recorders did not: _track_from_3mf in services/usage_tracker.py:907 (internal Filament Inventory) and store_print_data in services/spoolman_tracking.py:223 (Spoolman mode) both called the extractor with no plate_id and summed every plate. Per feedback_inventory_modes_parity both modes had to ship in the same drop, AND per the verification pass after the initial implementation: the direct-Print path (api.reprintArchive / api.printLibraryFile with plate_id: selectedPlate in PrintModal/index.tsx:739/750) hits the same bug because it never goes through the queue — caught before merge by tracing the frontend dispatch surface end-to-end. Fix — two complementary captures: (1) PrintSession gains a plate_id: int | None field; on_print_start queries PrintQueueItem for the printer's currently-printing row and records queue_item.plate_id onto the session — covers the queue path. (2) register_expected_print in main.py accepts a new plate_id parameter and stores it in a parallel _print_plate_ids: dict[int, int] dict (mirror of _print_ams_mappings); background_dispatch.py's 2 register sites and print_scheduler.py's 1 register site now pass plate_id (the dispatch already resolved it via _resolve_plate_id; reordering the resolve to run before register is a no-op since the resolver is pure). At expected-print promotion, main.py injects _print_plate_ids[archive_id] into _active_sessions[printer_id].plate_id (only when the session has no plate_id yet — queue captures win), mirroring the existing ams_mapping injection pattern. The dict drains on on_print_complete and on TTL eviction of the matching _expected_prints entry — same lifecycle as _print_ams_mappings. (3) _track_from_3mf accepts a new plate_id kwarg, threads it from session.plate_id, and passes it to extract_filament_usage_from_3mf. (4) store_print_data accepts a plate_id kwarg; the 3 call sites in main.py pass _get_start_plate_id(archive_id) (new helper, parallel to _get_start_ams_mapping); within store_print_data the caller value wins, falling back to queue_item.plate_id for the queue path. The PrintArchive's filament_used_grams stays file-level summed by design (#1593's contract — the archive describes the file, not the run); only the per-run usage attribution becomes plate-aware. What this intentionally does NOT touch: for direct Print of a single-plate file, _resolve_plate_id returns 1 → registered as plate_id=1, which extracts plate 1 = the whole file — identical to the prior no-filter behaviour. The change is observable only for multi-plate 3MFs where a specific non-first plate was dispatched. Tests: 9 new across test_usage_tracker.py + test_spoolman_tracking.py + test_print_start_expected_promotion.py — plate_id propagation through _track_from_3mf; absence leaves it None; on_print_start captures queue_item.plate_id; on_print_start no-op when no queue item; Spoolman-mode plate-scoped extract; register_expected_print stores plate_id in _print_plate_ids; _get_start_plate_id reads it back; injection into session for direct-Print (no queue capture); guarded against overwriting an already-captured queue plate_id. The pre-existing test_prefers_explicit_ams_mapping_over_queue_mapping updated for the new unconditional queue lookup (was conditional, now always queries to capture plate_id). Full 5830-test backend suite green. Ruff clean across the entire backend, not just touched files.
• AMS slots with a spool loaded but no material configured now show "?" instead of "Empty" (#1694, reported by kleinwareio) — On a 3-AMS P1S the reporter's screenshot showed AMS-C slots labelled "Empty" even though spools were physically loaded; OrcaSlicer's Device view showed the same slots as loaded. Root cause: the compact label below the AMS slot circle in PrintersPage rendered tray.tray_type || t('ams.slotEmpty'), falling back to "Empty" whenever the printer firmware hadn't been told which material is in the slot. The codebase already had a getEmptySlotKind helper that distinguishes 'physical' (firmware confirmed empty via state 9/10) from 'reset' (tray_type absent but firmware hasn't confirmed empty — i.e. spool loaded, just unassigned). The hover-card / circle border already used that distinction (line 814+ comment); the compact label did not. Fix: label now branches on emptyKind — 'physical' keeps "Empty" (the firmware-confirmed empty case), 'reset' shows "?" (matching the slicer's own convention for "loaded but unknown material"). External / VT tray label is unchanged (external trays have no "configured/unconfigured" distinction — they're either loaded or not). The SpoolBuddy kiosk's AmsUnitCard was carrying the same bug and got the same fix (mirror of getEmptySlotKind, "?" vs "Empty" label, tooltip "Spool loaded — slot not configured"). i18n: new ams.slotUnconfigured: '?' key added to all 11 locales (de / en / es / fr / it / ja / ko / pt-BR / tr / zh-CN / zh-TW) — value is universal so it's identical in every locale. The existing ams.emptySlotReset = 'No filament assigned' tooltip surface in FilamentHoverCard already covers the "what does this mean" question on hover, so no new tooltip key needed for the main card. Tests: AmsUnitCard vitest gains shows "?" for loaded-but-unconfigured slot (#1694) pinning both branches in one render (one slot with state: 9 → "Empty", one with no state → "?"). Existing AMS tests stay green (9/9 SpoolBuddy AmsUnitCard; AMS load/unload page tests untouched and green); i18n parity green (5100 leaves × 11 locales); frontend build clean; ESLint clean.
• Virtual Printer MQTT no longer disconnects idle OrcaSlicer at keepalive×1.5 (#1548 round 2, reported by hollajandro) — Round 1 (commits b663605 + 4ffefa6) shipped the keepalive parser + 1.5× idle disconnect per MQTT spec §4.4 and a per-minute status-push diagnostic. Reporter's follow-up pcap proved the round-1 logic was correct as designed, but exposed the actual root cause: the same OrcaSlicer install which stays connected to a real Bambu P1S indefinitely sends zero MQTT packets after the initial CONNECT / SUBSCRIBE / pushall / get_version burst — no PINGREQ at all — so any §4.4-compliant server disconnects it at keep_alive × 1.5. Real Bambu firmware does not enforce §4.4 (verified: the reporter's identical Orca install holds an idle session against real hardware on the same network), so spec compliance is itself the regression. Fix: after CONNECT/auth, drop the application-level read timeout entirely (read_timeout = None) and set SO_KEEPALIVE on the underlying socket so the OS TCP stack detects truly dead connections within a few minutes. The 60 s pre-CONNECT timeout is preserved — a client that opens TCP but never sends CONNECT still gets reaped to prevent half-open resource leaks. Negotiated keepalive is still parsed and now logged at INFO ("MQTT client … authenticated (negotiated keepalive=Xs, idle disconnect disabled)") for support-bundle visibility. Tests: TestHandleClientIdleConnection adds test_idle_client_stays_open_past_one_and_a_half_times_keepalive (negotiates keep_alive=2, sits idle for 4 s, asserts handler still running and writer not closed — direct round-1 inversion), test_so_keepalive_set_on_socket_after_connect pins setsockopt(SOL_SOCKET, SO_KEEPALIVE, 1) runs on the wrapped socket the moment auth succeeds. PINGREQ test docstring updated since there's no longer a timeout for it to "reset". All 33 VP MQTT server tests green; ruff clean. After this ships, OrcaSlicer should stay connected to the VP indefinitely while idle and reconnect cleanly on real network drops.
• System page now reports the container's uptime / boot time, not the host's (#1690, reported by IndividualGhost1905) — Reporter on Proxmox LXC observed that System → Uptime / Boot Time matched the Proxmox host's values, not the container's. Root cause: psutil.boot_time() reads /proc/stat:btime, which on shared-kernel containers (Docker, LXC) is the host kernel's boot time — leaking the host's lifecycle into Bambuddy's UI. Fix: read PID 1's create_time instead — psutil.Process(1).create_time() returns the POSIX timestamp of the init/entrypoint process, which in a container is the container's start time, and on bare metal / VMs is the host init (effectively identical to psutil.boot_time() within a sub-second). Defensive psutil.Error / OSError fallback to the old psutil.boot_time() for the rare case where /proc/1/stat is unreadable (locked-down container, custom seccomp policy). No frontend / i18n change — the field shape is unchanged, only the value is now correct on container installs. Tests: 2 new integration cases — one pins that the route reads Process(1).create_time and that the response uses that timestamp (not boot_time), the other pins the fallback path via a real psutil.NoSuchProcess(1) so the endpoint still returns 200 with the best-available answer. All 8 pre-existing system-info tests updated to also mock the new code path; full system API suite 20/20 green; ruff clean.
• Profile editor filament type dropdown now lists PLA-CF and the other Bambu CF / GF / specialty materials (#1686, reported by Bgabor997) — Creating or editing a filament preset on the Profiles page (BL Cloud, Orca Cloud, and Local Profiles all open the same shared editor) only offered 11 base materials (PLA, ABS, PETG, TPU, PA, PA-CF, PET-CF, PC, ASA, PVA, HIPS). Reporter on P1S wanted to tag a custom preset as PLA-CF — the dropdown source had no entry, so the saved preset's filament_type was wrong and the printer received the wrong material code at dispatch. Root cause: backend/app/data/filament_fields.json (served by GET /cloud/fields/filament and consumed by ProfilesPage via getCloudFields) shipped a curated subset that pre-dated Bambu's CF/GF lineup expansion. Other surfaces in the codebase already named the canonical list (utils/filament_ids.py GENERIC_FILAMENT_IDS, spool-form/utils.ts MATERIALS, the Bambu filament-id catalog in cloud.py), so the gap was specifically in the editor's allowed-values JSON. Fix: expanded the filament_type select to 25 BambuStudio-aligned options grouped by family — PLA (+ CF/GF/AERO), PETG (+ CF), ABS (+ GF), ASA (+ CF/GF), PC, PCTG, PA family (+ CF/PAHT-CF/PA6-CF/PA6-GF), PET-CF, TPU, PPS family (+ CF/GF for X1E), PVA, HIPS. No frontend, no i18n (material codes are universal). K-profiles editor unaffected — it picks filament_id, not filament_type. Tests: 15 unit cases in test_filament_fields_options.py pin every newly-added variant (PLA-CF, PLA-GF, PLA-AERO, PETG-CF, ABS-GF, ASA-CF, ASA-GF, PCTG, PAHT-CF, PA6-CF, PA6-GF, PPS, PPS-CF, PPS-GF) plus the baseline-must-still-be-present guard so a future curation pass can't silently drop them.
• Native systemd install no longer fails when INSTALL_PATH is under /home (#1685, reported by Geoff-S) — bambuddy.service shipped with ProtectHome=true, which makes /home/* invisible to the service namespace. When the user installed into /home/bambuddy/ (instead of the default /opt/bambuddy/), the ExecStart=/home/bambuddy/venv/bin/uvicorn path couldn't be resolved at exec time and the unit failed with status=203/EXEC: Unable to locate executable. The ReadWritePaths=$INSTALL_PATH directive doesn't reliably re-expose /home/* subpaths for executable resolution. Fix: install/install.sh now detects INSTALL_PATH == /home/* and emits ProtectHome=read-only for that case; the default /opt/bambuddy/ install keeps the stricter ProtectHome=true. The manual deploy/bambuddy.service template defaults to ProtectHome=read-only with a comment explaining when to tighten it to true. read-only keeps /home immutable to the service (no security regression — the service can read its venv but not write anywhere outside the ReadWritePaths allowlist).
• VP settings card now shows the target printer's serial in proxy mode — On a proxy-mode VP, the runtime services (SSDP advertisement, MQTT bind identity, certificate subject) all use the target printer's actual serial via target_printer_serial or self.serial (manager.py:235, 941, 957), but the /api/v1/virtual-printers response — which feeds the VP settings card — always returned the self-generated suffix-based serial from _get_serial_for_model(model_code, vp.serial_suffix). The card therefore displayed a serial that didn't match what the bridge actually advertises and what the slicer sees, breaking the visual "one identity per VP" mental model. Fix: _vp_to_dict (api/routes/virtual_printers.py:77) is now async and accepts db; when vp.mode == VP_MODE_PROXY and vp.target_printer_id, it issues a single SELECT serial_number FROM printers WHERE id = vp.target_printer_id and substitutes the result into the response serial field. Archive / queue / review modes keep the self-generated serial — those modes synthesise their own identity and never speak the target's. Defensive fallback when the target row is missing (printer deleted mid-config, manual SQL tweak, race between delete-printer and read-VP): the response falls back to the self-generated serial so the card still renders and the user can fix the target, rather than the API 500-ing. All 4 _vp_to_dict call sites (list, create, get, update) updated to await with db. Tests: 3 new in TestVirtualPrinterSerialSurface — proxy VP returns target serial across all three response paths (create / get / list), non-proxy VP with a target still uses the self-generated serial, orphaned proxy VP falls back to self-generated. Full VP API suite stays green (34/34); VP unit suite stays green (126/126); ruff clean.

Added

• Inventory page now supports native CSV import / export (#1576, PR #1659 by samedyuksel) — Bulk-add spools without manually clicking through the form, and back up / migrate the local inventory in a single round-trip. Export downloads bambuddy-spools-YYYY-MM-DD.csv (header + one row per active spool); Import shows a preview table that classifies each row as valid / error / skipped before anything hits the database, then a confirm click persists only the valid rows in one transaction (invalid rows are skipped, the user fixes them and re-uploads). Local inventory only — in Spoolman mode the buttons render disabled with a tooltip pointing at Spoolman's own CSV import/export, since the Spoolman backend has its own data store. Schema: fixed 18 columns, case- and whitespace-tolerant headers, includes weight_used, last_used, and the SpoolCreate fields storage_location / category / low_stock_threshold_pct so the round-trip preserves the per-spool location data from #1291. remaining is a derived, export-only column (label_weight - weight_used, clamped at 0) — it's written for human readability and ignored on import (weight_used is the source of truth, accepting both would let them contradict). Colour resolution: explicit rgba wins, otherwise brand + color_name resolves against the Color Catalog (case-insensitive, single in-memory pass — no N+1); a catalog entry with material = NULL is treated as the project's "matches any material" convention so a generic match counts as exact rather than firing the cross-material warning. Validation reuses SpoolCreate so every constraint that already protects manual adds (weight_used >= 0, weight_used <= label_weight, low_stock_threshold_pct range, etc.) protects bulk imports too. Hardening: 5 MB upload cap with a structured csv_import_too_large 413 response — Bambuddy doesn't have a global HTTP-level cap so the check lives on the route, and the implementation is a bounded 64 KB chunked read that bails the moment the accumulated body crosses the cap (file.size is None for chunked uploads so the loop is what actually prevents the OOM, not the pre-check). Spreadsheet formula-injection guard: every exported cell starting with = / + / - / `` / tab / CR is prefixed with a single quote on export, and the inverse strip on import keeps the round-trip lossless instead of accumulating quotes on every cycle. Soft-warn surface in the preview: a duplicate_of_existing flag fires when an active spool with the same material + brand + color_name exists (single SELECT, no N+1) so a double-click or re-upload of the same CSV doesn't silently duplicate the inventory — the row still imports (Spool has no unique constraint, by design), but the preview renders a Copy icon + tooltip so the user knows. Frontend: new `SpoolCsvImportModal` (file pick → preview table with per-row status / colour swatch / warnings → confirm imports valid rows) wired to Import + Export buttons on the inventory header; swatch rendering uses the existing `getSwatchStyle` helper so alpha=00 shows the checkerboard underlay instead of rendering as solid black, matching the rest of the inventory surface. i18n: new `inventory.csv` namespace with full translations in all 11 locales (de/en/es/fr/it/ja/ko/pt-BR/tr/zh-CN/zh-TW). Tests: 25 backend integration cases pin every behaviour — export shape, import dry-run vs real, color resolution (catalog hit, explicit rgba wins, cross-material flagged, exact-material match, generic-material match not flagged), 5 MB rejection, weight_used bounds, formula-injection round-trip without quote accumulation, dated filename, extra-column round-trip, duplicate-warn flag. Plus 3 frontend modal tests. Full backend suite + ruff + ESLint + frontend build + i18n parity (5092 leaves × 11 locales) green. Companion docs: wiki PR maziggy/bambuddy-wiki#41 documents the schema, behaviour, and the Spoolman-mode disabled-with-tooltip semantics.

Fixed

• Print modal now exposes a "Nozzle Offset Calibration" toggle for dual-nozzle printers (#1682, reported by louiskleiman) — Reporter on H2D running diamond nozzles: BambuStudio exposes a per-print "Nozzle Offset Calibration" option that is incompatible with diamond hot ends, but Bambuddy had no way to control the same flag, so every dispatch silently set it to the firmware default. Root cause: the field was hardcoded. bambu_mqtt.py:3445 always wrote "nozzle_offset_cali": 2 (skip) into the MQTT project_file payload, regardless of model, regardless of any user choice. The wire format is tri-state — 1=run, 2=skip — and matches BambuStudio's encoding; the manual-calibration route (/printers/{id}/calibration) already wired the corresponding cali_idx=2 MQTT command, but the dispatch-time toggle was simply absent. For most users this was invisible (BambuStudio's default is "run" on H2D / H2D Pro / H2C / X2D, Bambuddy's default was effectively "skip"), but a diamond-nozzle setup that needs the calibration explicitly off had no way to confirm Bambuddy's behaviour or override it the other way once we add a toggle that follows the slicer's default. Fix: end-to-end plumbing of nozzle_offset_cali with a hard MQTT-layer gate on dual-nozzle. start_print() (bambu_mqtt.py:3300) gains a nozzle_offset_cali: bool = False kwarg and the project_file payload line becomes "nozzle_offset_cali": 1 if (nozzle_offset_cali and is_dual_nozzle) else 2. The dual-nozzle check reuses is_dual_nozzle_model() and the runtime _is_dual_nozzle flag (set when device.extruder.info has ≥ 2 entries) — same canonical signal the rest of bambu_mqtt.py uses for routing decisions. Even if a stale queue item from when the printer was misidentified carries the flag, the MQTT layer downgrades it to 2 so firmware never tries to calibrate a head it doesn't have. The kwarg threads through printer_manager.start_print(), both background_dispatch call sites, and print_scheduler._start_print so every dispatch path — direct reprint, library file, queue-dispatched, watchdog-recover — respects the per-item setting. Persistence: print_queue.nozzle_offset_cali column (BOOLEAN DEFAULT TRUE, branched on is_sqlite() because Postgres rejects DEFAULT 1 for BOOLEAN, caught by my Postgres test environment before this shipped) — default TRUE matches BambuStudio's behaviour on dual-nozzle, the MQTT gate makes the value a no-op on single-nozzle. New default_nozzle_offset_cali setting (default TRUE) plumbed through schemas/settings.py, the settings PUT allowlist, and the SettingsPage card — the row in Settings → Default Print Options only renders when printers.some(p => p.nozzle_count === 2), so single-nozzle-only users never see a control they can't act on. ReprintRequest + FilePrintRequest schemas (schemas/archive.py, schemas/library.py) carry the field too so the API surface is consistent across the three "send 3MF to printer" routes. Frontend: PrintOptionsPanel (components/PrintModal/PrintOptions.tsx) accepts a showDualNozzleOptions prop and filters the option list; PrintModal/index.tsx computes it from selectedPrinters.some(p => p.nozzle_count === 2) in printer-mode or from a small inline DUAL_NOZZLE_MODELS set in model-mode (mirrors the backend DUAL_NOZZLE_MODELS frozenset: H2D, H2DPRO, H2C, X2D). The same gate flows through QueuePage bulk-edit — the new tri-state toggle only renders if any registered printer has nozzle_count === 2. Labels reuse the existing settings.defaultBedLevelling / settings.defaultFlowCali / etc. translation keys (identical strings, already translated) to keep i18n churn proportional to the actual new copy. i18n: 3 new keys per locale × 11 locales = 33 entries — settings.defaultNozzleOffsetCali, settings.defaultNozzleOffsetCaliDesc, queue.bulkEdit.nozzleOffsetCali — real translations in every locale (de / en / es / fr / it / ja / ko / pt-BR / tr / zh-CN / zh-TW), no English fallbacks. i18n parity check confirms 5069 leaves × 11 locales. Tests: 4 new in test_bambu_mqtt.py pin the four-quadrant gate: default value (P1S, no kwarg → 2), single-nozzle ignore (P1S, kwarg True → still 2 — the safety net), dual-nozzle honour (H2D, True → 1), dual-nozzle false (H2D Pro, False → 2 — the diamond-nozzle case). test_printer_manager.py updated for the new kwarg in assert_called_once_with. Frontend tests: existing PrintModal / QueuePage / SettingsPage suites pass with the new field threaded through (117 / 117). Full backend suite: 3840 / 3840 pass. ruff clean; frontend build clean; ESLint clean; i18n parity green.
• "Assign Spool" no longer claims the AMS slot was configured when it wasn't (#1680, reported by kleinwareio) — Reporter clicked Assign Spool from the printer card for AMS-B slot 4 while that slot was empty. The toast said "Spool assigned and AMS slot configured" but the AMS card kept showing slot 4 as Empty. Root cause: misleading toast on the empty-slot deferred-config path. The backend (inventory.py:1385-1405) deliberately skips the MQTT ams_filament_setting publish when the AMS reports an empty tray state (state ∈ {9, 10}) because Bambu firmware silently drops the push for empty slots — there's no point sending a command the printer will discard. The assignment row is persisted with pending_config=true, and on_ams_change (main.py:1031-1054) re-fires the full configuration the moment the AMS reports a non-empty fingerprint in that slot. The flow is correct; the success log line Pre-configured assignment: spool 16 → printer 1 AMS1-T3 (slot empty, will configure on insert) confirms the backend did exactly that. But the frontend ignored the response flag. AssignSpoolModal.tsx:153 always called showToast(t('inventory.assignSuccess'), 'success') — the wording "Spool assigned and AMS slot configured" — regardless of whether the backend actually configured the slot or deferred. The sibling SpoolBuddy modal (spoolbuddy/AssignToAmsModal.tsx:212-226) already branched on pending_config and showed a distinct "Slot will configure when you insert the spool" message; the printer-card modal was just never updated to match. Fix: AssignSpoolModal.tsx now reads newAssignment.pending_config and picks between 'inventory.assignSuccess' (slot configured immediately) and the new 'inventory.assignPendingInsert' ("Assigned. Slot will configure when you insert the spool.") key. Spoolman-mode branch unchanged — the Spoolman backend route always sends the MQTT push (no pending_config flag is exposed) and the SpoolBuddy modal's existing comment documents that. i18n: new inventory.assignPendingInsert key in all 11 locales (de / en / es / fr / it / ja / ko / pt-BR / tr / zh-CN / zh-TW), translations copied verbatim from the existing parallel spoolbuddy.modal.assignPendingInsert entries so the message reads identically across the app. No English fallbacks per the project's hard rule; i18n parity check confirms 5066 leaves × 11 locales. Tests: 2 new in AssignSpoolModal.test.tsx — shows the pending-insert toast when backend returns pending_config=true (#1680) pins the new branch (slot-was-empty case the reporter hit), and shows the configured toast when backend returns pending_config=false (#1680) is the counterpart regression guard so a future refactor can't silently mark every assign as pending. Both also assert the WRONG toast is NOT also called (defense against accidental double-toast). 16/16 AssignSpoolModal tests pass; frontend build clean; ESLint clean.
• Restarting Bambuddy mid-print no longer marks the live archive as "cancelled / aborted" + duplicates it + double-counts filament (#1679, reported by IndividualGhost1905) — Reporter on X1C, daily build v0.2.5b1-daily.20260607: a print was running, the host was restarted (planned reboot / power outage / watchtower image update), and Bambuddy's printer card showed the print as cancelled while the printer continued printing happily. Print log showed aborted for that row, filament usage was deducted at the cancellation moment (48.6 g / 5 % in the supplied screenshots), and when the print actually finished a second archive was created and filament was deducted again. Net effect: filament inventory off by the entire print weight, statistics showing one "user-cancelled" entry alongside one "completed" entry for the same physical print. Second confirmed hit from the same reporter, plus a corroborating comment from Arn0uDz on watchtower-driven restarts. Root cause: connected-edge reconciliation fired on a bare MQTT-connected state that had no real data yet. On Bambuddy startup, a fresh BambuMQTTClient is constructed with PrinterState defaults — most importantly state.state = "unknown" and state.subtask_name = "". The MQTT _on_connect callback (bambu_mqtt.py:668-669) broadcasts on_state_change(self.state) immediately after the broker accepts the connection — BEFORE the _request_push_all round-trips with the printer's real status. on_printer_status_change (main.py:825) sees state.connected=True flip on the connected-edge, spawns reconcile_stale_active_prints for that printer. The reconcile walks every archive in status="printing", calls _is_active_archive_stale (main.py:3352) — which sees state.state="UNKNOWN" (skips the IDLE/FINISH/FAILED branch), then state.subtask_name="" (matches trigger 3, "printer subtask_name empty") and returns stale. A synthesised aborted PRINT COMPLETE fires for every in-flight archive on every printer, clears _active_prints, and when the real PRINT COMPLETE finally arrives at print end, _active_prints doesn't have the entry, so a brand-new archive row is created instead of overwriting the synthesised one. The pre-existing comment at _is_active_archive_stale ("the next real PRINT COMPLETE would have overwritten the status anyway") was wrong: the reactive completion handler uses _active_prints for lookup, not a join on filename/subtask_id, so the original row stays cancelled and a duplicate is born. Timing-dependent in practice — on hosts where the printer's first push_status response wins the race against the reconcile background task, state is real and reconcile doesn't false-positive; on slower hosts or busy MQTT brokers, the bare-connect-edge fires first and the bug hits. The reporter is on a slower-race host and saw it twice. Fix: two-layer guard. (1) Primary: on_printer_status_change now gates the reconcile spawn on state.state being a real value — state_known = bool(state.state) and state.state.upper() not in ("", "UNKNOWN") — so reconcile doesn't fire until the first push_status updates state.state to a real Bambu firmware value (RUNNING / IDLE / FINISH / PREPARE / SLICING / PAUSE / FAILED). When that real push arrives, on_printer_status_change fires again, the connected-edge flag is still False (we never set it), and reconcile runs against actual evidence. The existing #1542 mechanism — synthesising a missed PRINT COMPLETE for prints that finished during a disconnect window — keeps working: if the printer reports IDLE on its first real push after reconnect, reconcile catches it the way it always did. (2) Belt-and-braces: _is_active_archive_stale now returns (False, "") when state.state is empty / "unknown" / None, regardless of the subtask fields. Strictly more conservative than the previous behaviour; only suppresses the degenerate-input false positive. Any future caller that bypasses the primary gate still can't synthesise an aborted completion from defaults. Tests: test_reconcile_stale_active_prints.py 26 cases (up from 21) — new parametrize test_pre_push_state_returns_not_stale_even_with_empty_subtask pins all five degenerate forms ("unknown", "UNKNOWN", "Unknown", "", None) and asserts none triggers stale even with empty subtask_id + empty subtask_name. The existing #1542 regression coverage stays green — terminal-state, subtask-id-mismatch, and empty-subtask-name-under-RUNNING all still report stale on real state pushes. Full backend suite: 3836 / 3836 pass. ruff clean.
• Print queue no longer wedges in "Currently Printing" when a printer accepts project_file but never starts (#1678, reported by kleinwareio) — Reporter on two P1S, one was power-cycled mid-print and came back online; from then on Bambuddy showed the next queue item as "Currently Printing" at 0% while the printer card showed "Idle / Ready to print". The same file also re-appeared in the Queued list as Pending after the user resubmitted. Only restarting the Bambuddy container ever recovered it. Support log + screenshots confirm: at dispatch time MQTT project_file was ACK'd, printer pushed gcode_state=IDLE, gcode_file=<our-file>, subtask_id=<our-submission-id> — i.e. the file landed on the printer but the printer never transitioned IDLE → PREPARE → RUNNING. Root cause: _watchdog_print_start returned SUCCESS as soon as subtask_id advanced. The subtask_id-as-pickup-signal was added for H2D, which can sit at FINISH for ~50 s after accepting project_file before flipping to PREPARE (#1078) — but it's strictly a "command landed" signal, not "actually printing". When the printer accepts the file but then wedges (cloud+LAN re-auth dance after a power cycle, old firmware, partial network outage), the watchdog returned success, the queue row stayed at status='printing', the in-memory _expected_prints entry stayed registered (TTL is 2 hours and only clears the dict, not the DB row), and every subsequent queue item was blocked because the printer was still "in flight". This reporter's firmware (01.07.00.00, current is 01.08.x+) and bambu_cloud_token-enabled cloud+LAN mode make the post-power-cycle wedge measurably more likely on their box, but the queue-wedge bug applies to any printer that accepts a file but stalls before starting. Fix: split the watchdog into two phases. Phase A (up to timeout, default 90 s, unchanged behaviour) waits for either an active-state transition OR a subtask_id advance — if neither happens the publish was lost on a half-broken MQTT session (#887/#936) and we revert + force-reconnect (the original #967 recovery path). Phase B (new, up to phase_b_timeout, default 180 s) only runs when Phase A exited via subtask_id-alone: keep watching for the active-state transition. 180 s is ~3.5× the worst observed H2D FINISH → PREPARE delay (#1078), so the H2D path stays green. If Phase B times out the queue item is reverted to pending so the user can retry without restarting Bambuddy — and Phase B explicitly does NOT force a MQTT reconnect because subtask_id-advance proves the project_file landed and a forced reconnect mid-parse triggers 0500_4003 (#1150). Phase A's existing gcode_file-changed discriminator (#1150) stays put for the no-subtask-id-advance case. Tests: test_scheduler_watchdog.py 14 cases (up from 13) — the #1078 H2D regression test rewritten to step the status through Phase A (subtask_id advance with state=FINISH) then Phase B (state flips to RUNNING) and pin success; new test_reverts_when_subtask_advanced_but_state_never_active pins the #1678 wedge case (subtask_id advances, state stays IDLE for the full Phase B window → revert + NO force_reconnect call); new test_default_phase_b_timeout_is_180_seconds pins the new default so a future refactor doesn't silently shrink the H2D headroom. Existing #967 / #1150 / #1370 / disconnect / fallback / discriminator regression coverage all stays green. Wider scheduler + queue + dispatch test surface (305 tests) stays green; ruff clean.
• Service-worker activate handler no longer hangs first-install browsers (demo site stuck spinner + Firefox Corrupted-Content) — Reproduced live on the demo platform: a visitor lands on {session}.demo.bambuddy.cool/, the Printers page renders, but clicking any sidebar entry sticks the next page on a spinner; only a manual reload recovers. In Firefox the same race surfaces as a "Corrupted Content Error" with sw.js stuck in activating for the entire session. Root cause: the client.navigate(client.url) call added to the activate handler in sw.js (commit 18d534c9, shipped 2026-06-04 alongside the Orca Cloud landing) was intended to force kiosks running an old SW to reload after a deploy, but its only guard was client.url && typeof client.navigate === 'function' — neither distinguishes a first install from an upgrade. On every fresh origin (every demo session is a new subdomain, but also any browser visiting Bambuddy for the first time, or after clearing site data) the activate handler still fired the forced navigation: Chromium raced it against React Router's in-flight SPA mount and wedged the page; Firefox's event.waitUntil deadlocked on await client.navigate(...) because the SW intercepts its own document fetch while still activating, the document load aborts, and the SW never reaches activated. The "first install on a never-controlled client" guard the commit's comment claimed simply didn't exist in code. Fix: split the lifecycle correctly. sw.js activate handler is reduced to cache cleanup + clients.claim() (matches the standard PWA lifecycle and lets activation complete in low single-digit ms regardless of in-flight document state). The deploy-pickup reload moves to sw-register.js: capture hadController = !!navigator.serviceWorker.controller at script load (true ⇔ a previous SW was controlling the document), listen for controllerchange, and only location.reload() when hadController was true. A returning kiosk hits a new deploy → had a controller → reloads as before. A first-install visitor (no prior SW, or hard-refresh, or first demo session) → no controller → no forced navigation → React mount completes cleanly. CACHE_NAME bumped bambuddy-v29 → bambuddy-v30 and STATIC_CACHE bambuddy-static-v28 → bambuddy-static-v29 so existing browsers fetching the new sw.js drop the old CacheStorage in the same pass — without the bump the SW file byte content might equal the cached one and the upgrade installs nothing. The SpoolBuddy-kiosk unregister branch at the top of sw-register.js is unchanged (still wipes registrations on /spoolbuddy paths). The notificationclick handler in sw.js (open-tab-on-push) still uses client.navigate(url) — different code path, unrelated, unchanged.
• VP archive/queue names with & no longer render as & + tooltip corrected for BambuStudio 2.7.x reality (#1658 follow-up, reported by IndividualGhost1905) — Two bugs surfaced on the same screenshot set: (A) Metadata-mode archive and queue names showed PCB Vise & Solder Station where the 3MF's Title metadata is PCB Vise & Solder Station. Root cause: ThreeMFParser._parse_3dmodel (backend/app/services/archive.py:495-538) parsed the XML <metadata name="Title">…</metadata> payload via regex and stripped whitespace but never called html.unescape(). The raw & landed in the DB; React then auto-escaped the & again on render, producing &. The sibling parser ProjectPageParser (line 754) already had a loop-until-stable unescape and a comment explaining why ("content is often triple-encoded" — observed BambuStudio behavior), the makerworld-fields path just didn't share it. Fix: module-level import html and the same loop-until-stable unescape pattern in _parse_3dmodel, applied uniformly to all <metadata> values so Title, Designer, and any future fields all get peeled the same way. The loop terminates as soon as html.unescape() stops changing the string, so single-, double-, and triple-encoded payloads all converge to the correct value; plain ASCII passes through untouched. (B) Filename-mode showed the slugified project title (PCB_Vise_&_Solder_Station) instead of the user-typed Send-dialog text ("Main Parts"). This is NOT a Bambuddy bug — BambuStudio source confirms it. PrintJob.cpp:314-325 (src/slic3r/GUI/Jobs/PrintJob.cpp) reads BBL_DESIGNER_MODEL_TITLE_TAG (defined as "Title" in bbs_3mf.hpp) from the 3MF, slugifies it (space → _, unusable chars <>[]:/\|?*" → _, collapse runs of _, truncate to 100 chars), and unconditionally overwrites the user-typed m_project_name with it before sending. params.project_name becomes both the FTP filename and the MQTT subtask_name. The user-typed string never leaves BambuStudio when a Title metadata exists — there is no MQTT field carrying it, so Bambuddy has no recovery path. The previous tooltip ("handy if you renamed the job in the 'send to printer' dialog") promised something BambuStudio strips, and the previous reply to the reporter dismissed this as "OrcaSlicer-style upload, working as designed" which was wrong on BambuStudio 2.7.1.57. Fix: tooltip rewritten in all 11 locales (de / en / es / fr / it / ja / ko / pt-BR / tr / zh-CN / zh-TW) to spell out the BambuStudio behavior — both modes often produce the same string because BS overwrites the Send-dialog name with the 3MF Title field when present. Tests: 3 new in test_archive_service.py::TestThreeMFMetadataHTMLUnescape — Title with & unescapes to & (the reporter's exact case), Title with triple-encoded & peels all three layers (the BambuStudio worst-case ProjectPageParser already documents), plain Title=Benchy passes through unchanged (regression guard against accidentally munging non-encoded payloads). Full 104-test archive suite green; ruff clean; i18n parity holds (5065 leaves × 11 locales); frontend build clean.
• FTP passive-port pool now sliced per-VP (10 ports each) so bridge-mode Docker drops from ~3.5 GB to ~210 MB host RAM (#1646, reported by TheFou — followed up with corrections we acted on) — Reporter on a Linux Docker VM (network_mode: host not viable because other containers already bind the same ports) measured 2002 docker-proxy host processes spawned from the previously-exposed 50000-51000:50000-51000 range — one process per port per address family, ~3.5 MB RSS each, ~3.5 GB total that doesn't show up in docker stats because it's host-level not container-level. Root cause: shared port pool, treated as symptom not cause. VirtualPrinterFTPServer exposed PASSIVE_PORT_MIN/MAX as class constants (backend/app/services/virtual_printer/ftp_server.py:573-574), so every VP's FTP session passed the same (50000, 51000) range into _bind_passive_port and competed on the same 0.0.0.0 binds. The widening from 100 → 1001 ports in an earlier round had been collision-avoidance headroom for multi-VP-on-shared-bind, but the cost was paid by every install — including the reporter's single-VP install that only ever needed ~10 ports of headroom. Fix: per-VP non-overlapping slices, allocated by VP id. New module-level compute_passive_port_slice(vp_id) → (port_min, port_max) returns a 10-port window: VP id 1 → 50000-50009, VP id 2 → 50010-50019, …, VP id 100 → 50990-50999. Class constants are gone; VirtualPrinterFTPServer.__init__ now takes passive_port_min / passive_port_max instance args. manager.py computes the slice at server-construction time from self.id and passes it in. Result for the reporter (single VP): 10 exposed ports → 20 docker-proxy processes → ~70 MB instead of ~3.5 GB. Three VPs → 30 ports → ~210 MB. Wrap-around behaviour pinned: VP ids beyond PASSIVE_MAX_SLOTS = 100 wrap modulo 100 (an install that's churned through many VPs over time still produces a valid in-range slice). A same-slot collision (vp_id 101 lands on the same slice as vp_id 1) falls back to the per-session 10-attempt random retry that pre-#1646 code already had — same recovery, no regression. Compose default narrowed: docker-compose.yml now exposes 50000-50029:50000-50029 by default (covers 3 VPs out of the box) instead of the 1001-port range. The comment explains how to widen for more VPs (50000-500N9 for N = vp_count - 1) and that proxy-mode VPs still need 50000-50100:50000-50100 because proxy mode forwards the real printer's full range — that codepath uses a separate TCPProxy.FTP_DATA_PORT_MIN/MAX and isn't sliced (the real printer owns that range, not Bambuddy). Doc corrections in the same drop: the previous warning over-stated userland-proxy: false as "confirmed by the reporter" — TheFou had flagged it as theoretical, not tested; the new comment doesn't push it as a recommendation at all (it's a global daemon flag, too blunt for a per-container problem). The new comment also explicitly names Linux multi-service hosts (NAS, dedicated Docker VMs, Unraid, Synology DSM) as a primary bridge-mode audience instead of leaving the warning under a "macOS/Windows" framing that TheFou pointed out missed his use case. Acknowledges that host-mode default is a deliberate trade-off for SSDP discovery, not a security-blind default. Tests: 10 new in test_vp_ftp_port_slicing.py — compute_passive_port_slice pins: vp_id=1 starts at base, consecutive vp_ids get adjacent non-overlapping slices, no two distinct vp_ids within MAX_SLOTS share a port (exhaustive across all 100 slots), wraps modulo MAX_SLOTS, top slot stays within the documented pool, non-positive vp_ids clamp to slot 0 (defensive — never produce a negative port that would crash asyncio.start_server). Two VirtualPrinterFTPServer instance tests pin: two instances constructed with different slices stay independent (regression guard against re-introduci

Changelog truncated — see the full CHANGELOG.md for the complete list.