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.

Fixed

• Print-modal "off" toggles for flow_cali and nozzle_offset_cali now actually suppress the calibration stage (live-tested on H2D 01.x) — The Re-print / Schedule modal toggles for Flow Calibration and Nozzle Offset Calibration accepted the user's "off" choice and flowed it correctly through to the project_file MQTT publish — Bambuddy sent extrude_cali_flag: 2 and nozzle_offset_cali: 2 per our reading of "1 = run, 2 = skip" inherited from the #1478 / #1682 work. Live test on an H2D running firmware 01.x: with both toggles off in Bambuddy's modal, the printer's stg queue (the pre-print stage list firmware publishes via push_status) still included stage 8 ("Calibrating dynamic flow") and stage 39 ("Nozzle offset calibration") — and physically ran them at print start. The 2 value did NOT suppress the stage despite our earlier "skip and reuse stored PA" reading. Root cause: the encoding for the "off" wire value is 0, not 2. The 2 value appears to mean "skip the explicit calibration pass but still apply / verify the stored PA value via the calibration stage" — close to a no-op in terms of K-factor but the printer still queues the stage and runs the per-print physical sequence. 0 is what actually drops the stage from the stg queue. A real BambuStudio Send-dialog capture on the same firmware (proxy-mode VP echo) also showed 0 for both fields when calibrations are unchecked, contradicting the #1478 commit message which read 0 as "never sent by BambuStudio." Fix: bambu_mqtt.py::start_print — extrude_cali_flag is now 1 if flow_cali else 0 (was 2), and nozzle_offset_cali is 1 if (nozzle_offset_cali and is_dual_nozzle) else 0 (was 2). The dual-nozzle gate stays — single-nozzle prints continue to force-skip the nozzle-offset calibration their head doesn't support (#1682). 1 (run) is unchanged on both fields. Verification: live re-test on the same H2D with both toggles still off — stg: [29, 13, 4, 14, 3] (cooling, homing, filament change, nozzle cleaning, vibration comp). Stages 8 and 39 dropped out cleanly. What's NOT fixed: vibration_cali is a JSON false bool in both Bambuddy's and BambuStudio's wire format, and the H2D firmware queues stage 3 ("Vibration compensation") regardless of the bool value — this is firmware-side and not solvable at our dispatch layer with the current field. Captured as a follow-up to investigate whether a parallel vibration_cali_flag integer field exists. Tests: test_bambu_mqtt.py — test_p2s_uses_boolean_format flipped extrude_cali_flag == 2 → == 0; test_nozzle_offset_cali_default_is_skip, test_nozzle_offset_cali_ignored_on_single_nozzle, test_nozzle_offset_cali_false_on_dual_nozzle flipped == 2 → == 0; docstrings updated to reflect the #1721 finding. The 1 if user_wants branch in both tests for the "on" case is unchanged. 281/281 bambu_mqtt tests green; full backend suite 5941/5941 green with -n 30; ruff clean; frontend untouched (rebuild + i18n parity confirmed clean per feedback_run_all_ci_checks).
• Support-bundle log noise: VP bridge nudge + SD-card cleanup (#1721 adjacent, observed on reporter's A1) — Two warnings polluting every A1 support bundle on a healthy print. Neither was the cause of #1721's timelapse complaint — both are adjacent noise. (1) request_status_update: not connected — mqtt_bridge.py::_resolve_client calls _request_version + request_status_update immediately after attaching a raw-message handler so the bridge cache populates without waiting for the next periodic pushall. The bind frequently races the real printer's MQTT TLS handshake — a slicer-side reconnect re-resolves the client before the underlying session has reconnected, especially on A1 firmware which reconnects more aggressively than X1/H2/P. request_status_update logs [serial] request_status_update: not connected at WARNING on the not-connected return path. The nudge is a best-effort optimisation; the fall-through (next periodic pushall) populates the cache anyway, so the WARNING fires on routine, expected, recoverable state. Fix: gate both nudges on current.state.connected at the bind site. When the client comes up, the next _resolve_client tick re-enters this branch on identity change OR the periodic pushall in bambu_mqtt.py fills the cache — same end state, no benign WARNING. The WARNING in bambu_mqtt.py:3224 is unchanged: it's still a real signal for the other callers (/printers/{id}/refresh-status user API, bug-reporter helper) where "you asked for a refresh on a dead client" is genuinely worth logging. New test_post_bind_nudge_skipped_when_target_not_connected in test_vp_mqtt_bridge.py::TestBridgeLifecycle pins the contract. (2) SD card cleanup failed after 3 attempts ... (file may linger on SD card) — The post-finish helper in main.py deletes the uploaded file from the printer's SD card to prevent the ghost-print-on-power-cycle behaviour (#374, #1542). It tries up to three candidate paths (derive_remote_filename(archive.filename), then {subtask_name}.3mf, then {subtask_name}.gcode), each up to 3 times with 2 s backoff, then logs WARNING if all fail. delete_file_async returned bool — True for success, False for ANYTHING else (FTP 550 file-not-found, network error, auth fail, transient FTP error). The A1 firmware (and most other Bambu firmwares post-print) cleans the SD-card upload itself before our cleanup runs, every candidate FTP-DELE returns 550, all three retries × three candidates × 2 s sleeps fire, then WARNING. That WARNING shouldn't exist on a healthy print where the printer self-cleaned. The same shape exists in _cleanup_forced_timelapse (#1397) walking the four timelapse dirs. Fix: bambu_ftp.py now exports a DeleteResult enum (DELETED / NOT_FOUND / FAILED). BambuFTPClient.delete_file detects the 550 case via isinstance(e, ftplib.error_perm) and str(e).startswith("550") (same pattern already used in the download path for the symmetric FileNotOnPrinterError sentinel from #972). delete_file_async now returns DeleteResult. Both post-finish cleanup helpers (main.py::on_print_finished SD branch + _cleanup_forced_timelapse) only WARN when at least one candidate returned FAILED; an all-NOT_FOUND outcome logs DEBUG ("nothing to delete — printer likely self-cleaned"). The cleanup helper also no longer burns the 2 s × 3 retry budget on a NOT_FOUND result (550 will never recover by waiting); only FAILED triggers backoff. DELETE /printers/{id}/files/... returns 404 (not 500) on NOT_FOUND, more accurate for the user-facing UI. Three other production callers (print_scheduler pre-upload delete, two background_dispatch fire-and-forget cleanups) are unchanged at the call site — they discard the return value. Tests: test_delete_file and test_delete_file_async in test_bambu_ftp.py switched to the enum (3 cases each). 2 new regression tests in test_cleanup_forced_timelapse.py: test_forced_no_warning_when_every_dir_returns_not_found pins the #1721 path (every candidate dir → 550 → no WARNING, one DEBUG summary), test_forced_warns_when_any_dir_returns_failed pins the counterpart (any FAILED keeps the WARNING — that's the signal the maintainer wants). caplog asserts the log record's level + content directly. Full backend suite 5941/5941 green; ruff clean; frontend untouched (rebuild + i18n parity confirmed clean per feedback_run_all_ci_checks). No migration, no new i18n keys, no schema changes.
• Virtual printer external spool (vt_tray) went "invalid" right after a slicer filament pick (#1622 round 5, reported by shaddowlink) — On a P1S in non-proxy VP mode, the reporter picked a filament for the external spool slot in BambuStudio's Device tab and the slot immediately rendered as invalid (color only, no profile, no K-profile, no nozzle temps), but recovered after a virtual-printer reload. AMS slot picks worked correctly. Wire dumps (BAMBUDDY_VP_DUMP_WIRE=1) captured the asymmetry: the bridge's outgoing 1 Hz cached-as-base push delivered vt_tray = {tray_info_idx, tray_color} — 2 fields — where a real P1S sends ~20 (tray_type, state, remain, k, n, cali_idx, nozzle_temp_min/max, tray_uuid, xcam_info, ...). The same _out.json showed AMS slots with the full 24-field dict because _merge_ams_dict deep-merged them. Root cause: Bambu firmware sends a partial vt_tray incremental right after acknowledging an ams_filament_setting for ams_id=255 (external spool) — carrying just the fields the slicer's pick changed. The round-4 per-field accumulate (#1622 / da79944) carried over prev keys NOT present in new, but vt_tray IS present in new, so the cached dict was REPLACED wholesale with the 2-field partial. The next 1 Hz cached-as-base push handed the slicer the stripped vt_tray; BambuStudio rendered the slot as invalid. Reloading the VP forced a reconnect → pushall → full vt_tray restored, and the cycle repeated on the next pick. Fix: mqtt_bridge.py::_on_printer_raw now applies the same per-field accumulate one level deeper: for every top-level key whose prev AND new are both dicts, overlay new onto prev rather than replace. ams is explicitly excluded (already deep-merged by _merge_ams_dict). The same overlay protects device, online, upgrade_state, ipcam, upload, net against future firmware partials with the same shape; the net.info IP rewrite path is unaffected because _rewrite_net_info_ips runs against new_state["net"] before caching and the rewritten list overrides the cached one on overlay (only net.conf and friends, when sent without info, draw from prev now). Tests: new test_partial_vt_tray_update_overlays_onto_cached_full_dict regression case in test_vp_mqtt_bridge.py::TestPushStatusCache constructs the exact P1S wire shape — pushall with the full ~20-field vt_tray, followed by the {tray_info_idx, tray_color} partial that shaddowlink's dump captured — and asserts tray_type, state, remain, k, n, cali_idx, nozzle_temp_min/max, tray_uuid, id all survive while the two incoming fields take their new values. All 53 bridge tests stay green; 287/287 across the broader VP test surface (mqtt_bridge / mqtt_server / vp_wire / virtual_printer); ruff clean. Bridge code path only; no migration, no new i18n keys, no frontend touch.
• Library G-code preview returned raw ZIP bytes as text/plain for sidecar-sliced rows (#1709, root cause + fix from yanglei1980) — slice_and_persist writes its output as a .gcode.3mf (a ZIP container with embedded G-code) but persisted the LibraryFile row with file_type="gcode". The G-code preview endpoint at library.py::get_gcode short-circuits on file_type == "gcode" and streams the on-disk bytes with media_type="text/plain", so every preview of a sidecar-sliced row handed the embedded viewer the raw ZIP body (PK\x03\x04…) instead of toolpath text — the viewer rendered nothing. External-folder scans (#1600) already typed .gcode.3mf rows correctly and hit the unzip branch, so the bug was specific to the sidecar slice path. Plain .gcode uploads were unaffected (their on-disk bytes really are text). Fix: (1) forward — slice_and_persist now persists file_type="gcode.3mf", matching what _classify_file_type returns for the .gcode.3mf extension and what external-scan rows already use; (2) back-compat — get_gcode also routes to the unzip branch when the filename ends with .gcode.3mf, so rows already written under the bug self-heal on first preview without a DB migration. UI gates: three frontend call sites that gated badge colour or the preview-eye icon on file_type == "gcode" were extended to also accept "gcode.3mf" — FileManagerPage.tsx badge + viewer-affordance gate, ProjectDetailPage.tsx badge — so the new typing doesn't regress visuals. The print / queue / slice action buttons use filename-based helpers (isSlicedFilename, isSliceableFilename) that already accept .gcode.3mf, so they need no change. Tests: new test_library_get_gcode_recovers_legacy_gcode_type_for_3mf regression case in test_library_api.py constructs a row with file_type="gcode" + .gcode.3mf filename pointing at a real ZIP, asserts the response is text/plain, contains G28, and does NOT start with PK — pins the legacy-row recovery path. Existing test_library_get_gcode_endpoint_accepts_compound_file_type continues to cover the forward path. Full backend suite 5920/5920 green; ruff clean; frontend ESLint + npm run build clean; FileManagerPage / ProjectDetailPage / FileManagerExternalFolder vitests 69/69 green; i18n parity unchanged (no new keys). PR #1709 closed for CONTRIBUTING.md non-compliance (branched from main, no issue, template incomplete); root cause + fix shape preserved here on dev.
• Cloud + Orca Cloud preset resolver: pin type and from to CLI-accepted values (#1712 follow-up, reported by maziggy on the Mecha Mewtwo slice) — Removing bundle mode (entry above) routed every slot through the cross-tier preset resolver. Cloud-tier presets surfaced two latent shape mismatches that bundle dispatch had been masking by materialising preset JSONs from .bbscfg-on-disk. (1) type field: Bambu Cloud labels presets with type: "printer" / "print" / "filament", but the BambuStudio CLI's --load-settings parser only accepts "machine" / "process" / "filament". The user's first failing slice produced operator(): unknown config type print of file preset.json in load-settings with exit code -5; the sidecar surfaces this as a generic "The input preset file is invalid and can not be parsed." (2) from field: Bambu Cloud's filament detail endpoint routinely ships presets with empty from (or no from at all). The CLI's compatibility check rejects either with operator(): file ... 's from unsupported (the double space in stderr = empty value). Same -5 exit, same generic "input preset invalid" surface. The sidecar's normalizeFromField already maps "User" / "System" → "system", but it doesn't touch empty / missing values. Fix: _resolve_cloud and _resolve_orca_cloud now force type = _SLOT_TO_PROFILE_TYPE[slot] and from = "system" on the payload before json.dumps, mirroring what _resolve_standard already does for the standard-tier stub. Both fields are unconditionally rewritten — idempotent on already-correct payloads, and pinning to "system" is consistent with how Bambuddy presents these post-flatten presets to the CLI (no parent walk needed, the cloud detail comes back fully expanded). Tests: new test_cloud_rewrites_type_field_for_cli (7 parametric cases covering all six type-name variants Bambu Cloud emits plus the missing-type case), test_cloud_pins_from_field_to_system (4 cases: empty, already-system, GUI User, GUI System), and test_cloud_synthesises_from_field_when_missing (the actual Mecha Mewtwo failure shape) pin the resolver-level contract. Existing happy-path assertions for _resolve_cloud / _resolve_orca_cloud updated to include the new fields. 28/28 preset-resolver tests green, full backend suite 5919/5919 green, ruff clean. What this can NOT recover: if Bambu Cloud later starts emitting a from value other than empty / "User" / "System" that genuinely means something (e.g. "project"), Bambuddy will silently flatten it to "system" too. We accept that trade-off because the alternative is leaving "input preset invalid" failures on every cloud slice, and "system" matches how the sidecar's own resolver normalises the post-flatten state.

Removed

• Slicer Bundle (.bbscfg) import (#1712, reported by IndividualGhost1905) — Bundle import never delivered what users expected. BambuStudio's "Export Preset Bundle" only includes user-customised presets; system processes / filaments are deliberately excluded by BS. So a fresh-install user who only used stock processes (the common case) got back a bundle containing their printer + maybe four custom filaments + zero processes. Importing that bundle into Bambuddy and then opening the SliceModal flipped into bundle mode — which constrained the dropdowns to bundle contents only — and surfaced "no presets" for process, blocking slicing on STL (3MF still worked because the embedded process JSON bypasses the dropdown). The first round of #1712 (d459b6ea, 2026-05-XX) addressed cross-tier visibility / dedup / banner behaviour but didn't touch the bundle-mode dropdown trap. Investigating the second round made it clear the bundle import wasn't unlocking anything the existing tiers don't already cover — custom presets reach Bambuddy through Bambu Cloud sync, Orca Cloud sync, or Single Preset Import; standard presets come from the sidecar's /profiles/bundled route automatically — so bundle mode was a fourth code path delivering no unique value while gating users on a slot they couldn't populate. What was removed. Backend: POST/GET/DELETE /slicer/bundles* routes, SliceRequest.bundle field + SliceBundleSpec schema, the bundle-dispatch fork in library.py::_run_slicer_with_fallback (cross-class slice-all loop, normal slice branch, _resolve_target_printer_model short-circuit), the bundle-context query params on GET /library/files/{id}/filament-requirements and GET /archives/{id}/filament-requirements, the bundle-fingerprint key in slice_preview.py's LRU cache (back to (kind, source_id, plate_id, content_hash)), SlicerApiService.import_bundle/list_bundles/get_bundle/delete_bundle/slice_with_bundle, the BundleSummary / BundleNotFoundError types. Frontend: BundlePicker + BundleStringDropdown components, isBundleMode state and every branch on it in SliceModal.tsx, selectedBundleId / bundleProcessName / bundleFilamentNames state, the bundle-mode auto-pick effect, the bundle dispatch shape in buildSliceBody, the bundlesQuery itself, SlicerBundle / SliceBundleSpec types, listSlicerBundles / importSlicerBundle / deleteSlicerBundle API methods. The bundle-derived path in buildCompatibilityIndex is also gone — the function now only takes the printer-model registry and returns {bambuModelByShortCode}. presetCompatibility keeps its two remaining paths: the slicer's own compatible_printers list on local-imported presets (authoritative when set) and the BBL <code> name-based fallback against the printer-model registry. Tests: TestBundleRoutes / TestBundleClientMethods / TestSliceWithBundle / TestBundleAwarePreview / TestBundleDispatchShape classes deleted across test_slicer_presets.py / test_slicer_api.py / test_slice_preview.py / test_slice_request_schema.py / test_library_slice_api.py; the SliceModal's "Bundle tier" describe block and the bundle-only assertions in slicerPrinterMatch.test.ts deleted; SlicerBundlesPanel.test.tsx removed; TestNozzleClassGuard simplified (no more bundle vs preset request distinction). What replaces the Settings panel. SlicerBundlesPanel is kept under the same name and slot in SettingsPage but now renders a static notice (title: "Slicer Bundles (removed)") explaining the removal and pointing users at Single Preset Import / Bambu Cloud / Orca Cloud, with the slicer sidecar covering stock presets automatically. The notice is permanent and can be removed in a future cleanup. i18n. settings.slicerBundles.* block replaced with settings.slicerBundlesRemoved.{title,description,alternatives} translated across all 11 locales (de / en / es / fr / it / ja / ko / pt-BR / tr / zh-CN / zh-TW) per feedback_translate_dont_fallback. slice.bundle / slice.bundleNone / slice.bundleAllRequired keys removed across all locales. Parity check 5106 leaves × 11 locales green. Migration. Hard cutover, no automatic preset migration. Users who previously imported bundles will see them disappear from Settings → Slicer Bundles after this drops; their printer preset still lives on the sidecar bundle store but is no longer surfaced. Standard presets from the sidecar's BBL tree cover stock slicing; users who need their customs re-upload them via Single Preset Import or sync via Bambu Cloud / Orca Cloud. Why this resolves #1712. shaddowlink's failing path was: import bundle for H2D → bundle has 0 processes (BS-side limitation) → SliceModal flips into bundle mode → process dropdown empty → can't slice STL. Post-removal: same import isn't possible, but the cross-tier preset picker shows H2D processes from the sidecar's standard tier (which always had them — bundle mode was the thing hiding them), filtered by BBL H2D compatibility. STL slicing works without any user action. Tests: full backend suite 5907/5907 green; ruff clean; frontend ESLint clean; npm run build clean; vitest 158 files / 2118 tests green; i18n parity 5106 leaves × 11 locales green.

Added

• Support bundle now includes redacted cached push_status per connected printer — The existing support bundle (GET /support/bundle) shipped support-info.json + bambuddy.log — useful for triage, but missing the one thing that consistently blocks per-model work: the raw shape of the printer's MQTT push_status payload. Bambu firmware ships per-model config in a different shape for every family — AMS Backup detection was deferred in 85fbd7fc because the H2D's bit-26 of print.cfg doesn't translate to the X1C / P1S / P2S layout and we had no ground-truth samples to map them; the same gap surfaces every time a vt_tray / vir_slot / mapping shape varies across firmware (the P2S tray_now fix, the H2D vir_slot parsing, the round-5 vt_tray overlay fix from #1622 last week all needed wire samples to land). What's new: the bundle now contains a push-status/printer-{i}.json file per connected printer, indexed against support-info.json["printers"]. Each file carries {model, firmware_version, captured_at, raw_data} where raw_data is the live cached push_status from BambuMQTTClient.state.raw_data. Disconnected printers (no MQTT state, or raw_data empty) are skipped — there's nothing to capture and an empty file just adds noise. Redaction (two-pass): a structural pass via the new _redact_raw_push_status helper drops user-private top-level keys anywhere in the tree (subtask_name, gcode_file, gcode_file_prepare_percent, subtask_id, task_id, project_id, design_id, profile_id, model_id, gcode_state) — Bambu's per-print filename/cloud-ID surface — and rewrites every net.info[*].ip entry to "0.0.0.0", mirroring the LAN-topology leak fixed for the virtual-printer bridge in #1429. What's deliberately preserved: print.cfg, print.option, ams.*, vt_tray, vir_slot, mapping, ams_extruder_map, hardware fields (nozzle_diameter, temperatures, layer counters). These are the fields per-model work depends on. The structural pass then runs through sanitize_log_content with the same DB-derived sensitive_strings map the log path uses (printer names, serials, IPs, access codes, usernames, Bambu Cloud email) — belt-and-suspenders against any user-named string that leaked into a tray UUID or a sub-brand field. The redactor returns a NEW dict and never mutates the live state.raw_data (the dispatcher reads it on every tick; mutation would race the next push). Why always-on instead of opt-in: the bundle endpoint is already gated on "debug logging must be enabled" — generating the bundle is an explicit user act, the file downloads to the user's machine before they choose to send it, and forcing a second toggle adds friction without changing the threat model. Once a handful of bundles arrive from new-model users we'll have what we need to unblock AMS Backup awareness in the print-queue deficit check, plus future per-model shape variance. Tests: 5 new unit cases in test_support_helpers.py::TestRedactRawPushStatus pin the contract — drops the 9 user-private keys, rewrites net.info[*].ip while preserving mask siblings + sibling net keys, preserves print.cfg / ams / vt_tray / vir_slot / mapping / ams_extruder_map, does not mutate input, handles non-dict input gracefully (returns {} for None / list / str). Full support test surface 79/79 green (test_support_helpers.py + test_support_api.py); full backend suite 5937/5937 green with -n 30; ruff clean across the backend; frontend untouched but rebuild + i18n parity confirmed clean per feedback_run_all_ci_checks. No migration, no new i18n keys, no schema changes, no frontend changes.
• Re-print / Schedule modal: cross-extruder AMS slot picks on dual-nozzle (#1722, reported by privatsturm) — On a dual-nozzle setup (e.g. H2D with AMS A+C wired to the left extruder and AMS B wired to the right), the per-filament slot dropdown in the Re-print and Schedule modals used to hide every slot whose extruder didn't match the filament's slicer-assigned nozzle. A filament the slicer had assigned to the left extruder would only let the user pick from A or C; a right-assigned filament could only pick from B. Users who'd intentionally loaded the required filament into the "other" AMS — for example, AMS B (right side) carrying a colour the slicer had planned to print on the left — couldn't select it, even though the printer can physically run that AMS through its wired extruder. Three slice-output diffs (BambuStudio Desktop, OrcaSlicer Desktop, Bambuddy sidecar) all produced identical filament_map values for the same source 3MF, so the slicer wasn't the source of the asymmetry — Bambuddy's UI filter was. Behaviour: every loaded slot is now offered for every filament row in the Re-print and Schedule modals' specific-printer flow, regardless of which extruder it's wired to. The L/R badge on the filament row stays as a visual hint to what the slicer planned; the dropdown now trusts the user to pick based on their physical setup. Single-nozzle printers and FTS-equipped setups are unchanged — both short-circuited the filter already and continue to. Printer firmware accepts or rejects the resulting ams_mapping at start-print, so a physically-impossible pick fails loudly rather than silently. Implementation: FilamentMapping.tsx:248-254 carried a guard f.extruderId === item.nozzle_id on the slot dropdown's loadedFilaments filter; the guard is now removed. The single-nozzle and FTS short-circuits stay. Tests: 'still applies the per-nozzle filter when FTS is null' flipped to 'offers cross-extruder slots in the dropdown without FTS (#1722)' — same scenario (no FTS, AMS 0 on right, filament asking for left), but now asserts both slots ARE listed. The FTS-installed case (#1162) and the rest of the FilamentMapping suite stay green. Backend untouched; no schema, no i18n. 5/5 FilamentMapping vitests green; 1043/1043 full component sweep green; frontend build clean.
• 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

• Virtual printer cache drained capability/lifecycle fields between pushalls, greying out Device-tab UIs (#1622 round 4, reported by shaddowlink) — Reporter on a P1S in archive mode saw the AMS-slot filament dropdown empty and the "Manage calibration data" UI disabled in BambuStudio's Device tab, while the same panels worked correctly on his H2D. After three rounds of triage on the printer-side payload (which traced clean — bridge passes vt_tray byte-identical, tray_info_idx resolves, AMS slots populate), the actual asymmetry surfaced in the bridge cache dumps: P1S cached print state contained 17 top-level keys; H2D contained 99. The missing fields were exactly the capability/lifecycle gates BambuStudio reads to decide which Device-tab UIs to enable (cali_version, print_type, gcode_state, mc_print_stage, mc_stage, device, cfg, home_flag, the mc_* family, fan speeds — ~80 fields). Root cause: Bambu firmware sends a full top-level field set in pushall responses (on pushall request / printer reconnect) and ~1 Hz incrementals carrying just what changed (typically temps, fan, wifi, status). _on_printer_raw in mqtt_bridge.py cached the latest push as new_state = copy.deepcopy(print_data) — replacing the prior cache wholesale — then re-merged only a hand-picked allowlist (_SLICER_VISIBLE_STICKY_KEYS) of 14 keys back from prev. The allowlist covered the #1371 / #1387 / #1228 / #1558 failure modes but missed capability/lifecycle fields entirely, so every 1 Hz incremental drained ~80 fields out of the cache and the slicer's gated UIs flipped off as soon as the cache thinned. The code comment claimed the cache "mirrors the same preservation pattern Bambuddy uses for its own internal state in bambu_mqtt.py" but it didn't: internal state is updated per-field (if "X" in data: self.state.X = ...), never drops what it's seen, and accumulates monotonically. Fix: replace the allowlist-preserve with per-field accumulate. For every key in the prior cache, carry over verbatim when the incoming push omits it; let new values overwrite when present. The _merge_ams_dict deep-merge for partial ams blobs stays (#1387 / #1371 regression guards still pass). _SLICER_VISIBLE_STICKY_KEYS is removed entirely — the new logic is a strict superset of every case the allowlist handled. Why most P1S users don't hit it: timing. The typical workflow is connect → BS issues pushall → cache fills → click Device tab within seconds → UI works. shaddowlink's sequence kept BS idle long enough between pushalls that the cache thinned to incremental-only state before he clicked. X1C users hit the same drain but don't notice — older BS capability spec doesn't gate the same UIs on cali_version / mc_print_stage. H2D escaped detection because his captures happened to land close to a pushall reply (cache still fat). Tests: new test_incremental_push_preserves_non_allowlisted_capability_fields regression case in test_vp_mqtt_bridge.py::TestPushStatusCache constructs a full push with cali_version / print_type / gcode_state / mc_print_stage / mc_stage / device / cfg / home_flag, follows it with a temps-only incremental, and asserts every capability field survives. All 51 existing bridge cache tests stay green — same behaviour for the allowlist subset, plus the formerly-dropped fields. Bridge code path; no migration, no new i18n keys.
  — 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-

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