Backend correctly defers MQTT configuration when the AMS slot is empty
at assign time (state ∈ {9, 10}) — firmware drops the push silently;
on_ams_change replays the config once a spool is detected. The
response carries pending_config=true to communicate that. The
printer-card AssignSpoolModal was ignoring the flag and always
showing "Spool assigned and AMS slot configured" — the SpoolBuddy
modal has handled this since it shipped. Now mirrors the same
branch and shows "Assigned. Slot will configure when you insert
the spool." when pending_config is true.
on_printer_status_change fires from MQTT _on_connect BEFORE the first
push_status round-trips, when PrinterState is still on construction
defaults (state="unknown", subtask_name=""). The connected-edge
reconcile was treating that degenerate state as evidence and
synthesising aborted PRINT COMPLETE for every in-flight archive on
every Bambuddy restart. The reactive PRINT COMPLETE then created a
duplicate archive (lookup misses on cleared _active_prints), so
filament got deducted twice.
Two-layer guard: gate the reconcile spawn on a real state.state, and
make _is_active_archive_stale return not-stale on unknown/empty input
as defensive fallback. #1542 behaviour preserved — real stale archives
still get caught the moment a real push_status arrives.
_watchdog_print_start now treats subtask_id-advance as Phase A
"command landed", not as final success. Phase B (180s) keeps watching
for the active-state transition; if it never arrives — printer
accepted the file but stalled (cloud+LAN re-auth after a power cycle
on old firmware was the reported trigger) — revert the queue item to
'pending' instead of leaving it stuck in 'printing' until container
restart. Phase B skips force_reconnect because subtask_id-advance
proves the project_file landed; a reconnect mid-parse would trigger
0500_4003 (#1150). Phase A's H2D 50s FINISH→PREPARE tolerance (#1078)
is preserved by Phase B's 180s headroom.
Repro on every fresh demo subdomain: visitor lands on Printers OK, first
sidebar click sticks on a spinner (Chromium) or trips "Corrupted Content
Error" with sw.js stuck `activating` (Firefox). Manual reload recovers.
Root cause is the `client.navigate(client.url)` call added to the activate
handler in 18d534c9 (intended to force kiosks to pick up new bundles).
Its guard — `client.url && typeof client.navigate === 'function'` — does
not distinguish first install from upgrade. On any fresh origin (every
demo session, every first-time visitor, every cleared profile) it still
fired: Chromium raced it against the in-flight SPA mount; Firefox
deadlocked the activate's waitUntil on `await client.navigate(...)`
because the SW intercepts its own document fetch while still activating.
Split the lifecycle correctly:
- sw.js activate handler: just cache cleanup + clients.claim().
- sw-register.js: capture `hadController = !!serviceWorker.controller`
at load, listen for `controllerchange`, reload only when hadController
was true. Returning kiosk hits a new deploy -> had controller -> reloads
as before; first-install visitor -> no controller -> no forced nav ->
React mount completes.
Bump CACHE_NAME v29->v30 and STATIC_CACHE v28->v29 so existing browsers
fetching the new sw.js drop the old CacheStorage in the same pass.
SpoolBuddy unregister branch and notificationclick's client.navigate are
unrelated and unchanged.
ThreeMFParser._parse_3dmodel left XML-escaped values raw, so a Title of
"PCB Vise & Solder Station" landed in the DB as the literal "&" and
React re-escaped it on render to "&". Apply the same
loop-until-stable html.unescape() the sibling ProjectPageParser already
uses, uniformly across all <metadata> values.
Same drop: rewrite the VP archive-name-source tooltip in all 11 locales.
BambuStudio 2.7.x (PrintJob.cpp:314-325) overwrites the user-typed
Send-dialog name with the slugified 3MF Title field whenever one is
present, so the previous "handy if you renamed the job in the send dialog"
copy was false. New text spells out the actual behavior; both Filename
and Metadata modes often produce the same string for that reason.
The 50000-51000 docker-compose port range spawned ~2000 docker-proxy
host processes (~3.5 GB RSS) under Docker's default userland-proxy.
The 1001-port pool was symptom treatment — collisions only matter for
multi-VP-on-shared-bind, but the cost was paid by every install.
Each VP now gets a non-overlapping 10-port slice computed from its id
(VP 1 -> 50000-50009, VP 2 -> 50010-50019, ...). Class constants are
gone; VirtualPrinterFTPServer takes passive_port_min/max instance args.
Wraps modulo PASSIVE_MAX_SLOTS = 100, with the existing 10-attempt
random retry as same-slot collision fallback.
Compose default narrowed to 50000-50029 (3 VPs). Proxy-mode VPs forward
the real printer's full range and stay on the separate TCPProxy
constants. Compose comment rewritten to acknowledge Linux multi-service
hosts as a primary bridge-mode audience and drop an over-stated
"confirmed by reporter" claim about userland-proxy=false.
The print log's User column came from printer_manager.get_current_print_user,
but only background_dispatch (Archive Print, Library Print) ever populated
that dict. The Queue manual-start path went straight from
POST /queue/{id}/start into PrintScheduler._start_print, neither end
recording the clicker — so any print started from the queue landed in
PrintLogEntry with created_by_username NULL even with auth enabled.
Two-sided fix: /start now writes user.id to item.created_by_id when no
prior owner is set (preserves UI-added items' original uploader), and
PrintScheduler gains _propagate_owner_to_printer_manager called from
_start_print to hand the owner into set_current_print_user before the
print command goes out.
100vh and window.innerHeight report the layout viewport on iOS Safari, so
the popover's Start Drying button rendered behind the bottom toolbar overlay.
Switch the popover maxHeight to 100dvh and default computePopoverPosition's
viewportHeight to visualViewport.height (with innerHeight fallback). The
flip-above decision and the body-scroll fallback now both run against the
actually-visible area, so the footer button stays reachable on iPhone.
Two bugs in PrintScheduler._check_previous_success:
- Lookback excluded 'cancelled' so user cancellations were walked past
- Lookback included 'skipped', so one skip cascaded indefinitely
Swap to ['completed', 'failed', 'cancelled', 'aborted'] and accept
both 'completed' and 'cancelled' as predecessor success. Real
'failed' / 'aborted' still gate.
One-shot migration in run_migrations resets only the skipped items
whose true predecessor was cancelled — surgical reversal of the exact
bug fingerprint, leaves genuine failure-gated skips alone. Portable
across SQLite and Postgres, idempotent on re-run.
Cloudflare on bambulab.com now serves cf-mitigated=challenge to plain
Python TLS handshakes. Use curl_cffi.AsyncSession with impersonate="chrome"
for the two bambulab.com fetches (index page + per-model JSON); wiki and
CDN paths stay on httpx. HTTP User-Agent stays honest "Bambuddy/1.0" —
only TLS-handshake bytes match Chrome, per the compliance commitment.
Soft dependency — falls back to httpx with a startup warning when
curl_cffi isn't importable; wiki-based version detection still works.
Local build via Docker git context required `git` in the BuildKit worker,
which QNAP Container Station and Synology DSM don't provide. Both sidecar
images are now published to ghcr.io/maziggy/{orca-slicer-api,bambu-studio-api}
and docker.io/maziggy/{orca-slicer-api,bambu-studio-api}; compose pulls
:latest by default, SIDECAR_TAG=bambuddy-X.Y.Z pins per release.
Wiki, slicer-api README, .env.example, and CHANGELOG aligned. Build-from-source
path kept under "Building from source (advanced)" for forks / dev work.
Both images are linux/amd64 only — OrcaSlicer ARM64 on hold pending upstream
fix; BambuStudio doesn't publish ARM64.
asyncio holds only a weak reference to tasks returned by
``create_task``. Fire-and-forget callers that discard the return value
let the event loop GC the task before it finishes, logging
``Task was destroyed but it is pending!`` with no traceback. The #1648
support-bundle review surfaced 94 such warnings in 8 days of v0.2.4.5
-- the silently-vanished exceptions reach support bundles as opaque
GC notices instead of actionable errors.
New backend/app/core/tasks.py::spawn_background_task(coro, *, name=None)
is the one place in the codebase that calls asyncio.create_task. It
stores the task in a module-level set, attaches a done-callback that
auto-removes on completion AND surfaces any uncaught exception via the
logger with the originating traceback, and accepts name= so a leak
source is traceable through /tracebacks and the log line. Cancelled
tasks don't log (a shutting-down service is not an error).
Migrated the 16 truly-orphan create_task call sites to the helper:
main.py (8):
reconcile-stale, cooldown-poweroff, energy calc, smart-plug,
maintenance-check, photo-then-notify, layer-timelapse,
scan-timelapse, print-scheduler, notify-no-archive (the last one
was hand-rolling the same pattern with task + no-op done_callback)
printers.py:3123 apply-pa-after-refresh
print_queue.py:1034 queue cooldown-poweroff
firmware_update.py:261 firmware upload
archive.py:1514 timelapse mp4 convert
print_scheduler.py:2199 watchdog print-start
library.py:1614 STL backfill
smart_plugs.py:259 tasmota scan
discovery.py:159 subnet scan
smart_plug_manager.py x3 plug auto-off-pending
background_dispatch.py x2 (lambda-wrapped inside
loop.call_soon_threadsafe) upload progress
Sites that already kept strong refs are unchanged:
self._tasks.append(asyncio.create_task(...)) -- VP manager,
tcp_proxy, mqtt_server
self._x_task = asyncio.create_task(...) on service instances --
mqtt_bridge, obico_detection, github_backup, archive_purge,
local_backup, library_trash, discovery service
Locally assigned + awaited/gathered -- tcp_proxy bidirectional
pumps, camera_fanout, slice_dispatch, slicer_api progress_task,
manager._finish_release_task, main.py module-level cleanup loops
Reporter on an H2D + Polymaker PLA Matte spool noticed that assigning
the spool from the Dashboard left the slicer's filament dropdown
showing "unknown", but clicking Configure right after made the
slicer recognize it correctly. "Configure" felt like a mandatory
follow-up step rather than a refinement.
Bambu cloud uses three preset-ID shapes:
GFS… — Bambu official cloud preset
PFUS… — cloud user-created preset
PFCN… — cloud shared / partner preset (Polymaker's "(Custom)"
Bambu Lab H2D variants ship this prefix)
apply_spool_to_slot_via_mqtt only routed GFS and PFUS through the
cloud-detail lookup that extracts the underlying filament_id. PFCN
slipped past the cloud-lookup branch, fell into the local-preset
int() parse path, raised ValueError, dropped into
normalize_slicer_filament which returns any P-prefix unchanged, and
the raw PFCN landed in tray_info_idx. The printer's calibration
table can't index that, so the slicer rendered "unknown". The
Configure modal rescued every assign because it does its own
getCloudSettingDetail and writes the resolved filament_id.
Extend the cloud-detail-lookup branch (inventory.py:129) and the
discard safety net (inventory.py:223) to include PFCN alongside
GFS/PFUS. Three behaviours fall out:
* Cloud-authenticated: the real filament_id from
detail["filament_id"] ships as tray_info_idx (Polymaker PLA
Matte resolves to GFL05).
* Cloud unavailable: raw PFCN discarded, the slot reuses an
existing valid P-prefix preset if material matches.
Source comment now lists all three cloud-ID shapes so the next time
Bambu invents a new prefix the maintainer doesn't have to re-derive
the structure from a bug report.
Reporter on an A1 Mini saw the AMS slot Configure dropdown render no
Bambu / Generic filament profiles, and saw the Profiles tab strip
A1 Mini results when filtering by that model. Bambu rolled out a
profile rename mid-2026: the @BBL <code> suffix on 106 cloud profiles
shifted from the long display form to a terse model code -- e.g.
"Bambu PLA Basic @BBL A1 Mini ..." is now
"Bambu PLA Basic @BBL A1M ...". User-authored profiles still use the
long form. Bambuddy's filters did a verbatim uppercase compare
("A1M" vs "A1 MINI"), so every renamed cloud profile silently
disappeared from the picker.
Centralize the alias check in slicerPrinterMatch.ts. New
PRINTER_MODEL_SUFFIX_ALIASES table maps "A1 Mini" <-> "A1M"
bidirectionally; exported matchesPrinterModelSuffix() does the
case-insensitive compare with the alias fallback. Two consumer
sites swap to the helper:
* ConfigureAmsSlotModal.tsx (Orca cloud and Bambu cloud filter
branches) -- the AMS slot picker, hit directly and reached from
SpoolBuddy's AMS page via mapModelCode(printer?.model)
* slicerPrinterMatch.ts:classifyByBambuName -- the SliceModal
Process / Filament compatibility check
Backend printer_models.py also gets a "Bambu Lab A1M" -> "A1 Mini"
entry so server-side 3MF model normalization stays consistent if a
3MF ever embeds the short form.
Kept the alias table narrow on purpose. Wide-net aliasing (e.g.
"X1" <-> "X1C") would silently collapse physically distinct
printers. When Bambu introduces the next rename, it is one new row
in the table -- /api/v1/cloud/settings is the place to grep, called
out in the source comment.
Reporter on Bambu Studio 2.7.1.57 + X1C saw the Send modal stuck at
"Downloading" after sending to a Queue-mode VP. Delete-from-queue and
even Auto-Dispatch ON + a successful real print didn't release it.
Root cause: BS 2.7.x flipped the Send sequence from
MQTT project_file -> FTP upload -> done
to
FTP verify_job -> FTP .3mf -> MQTT project_file.
The #1280 fix sets gcode_state=FINISH in on_file_received (after the
FTP upload). Under the new order, the synthetic project_file ack in
_send_print_response then runs and overwrites _gcode_state back to
PREPARE. The 1 Hz cached-as-base push stream carries PREPARE forever,
the slicer never sees the FINISH transition it waits for, and the
modal sits stuck. Auto-Dispatch ON shares the cause: the real
printer's PREPARE->RUNNING->FINISH on the bridge gets masked by the
local _gcode_state override in _send_status_report.
Re-fire set_gcode_state("FINISH", filename, prepare_percent="100")
1.5 s after the project_file ack for every non-proxy mode (queue /
archive / review). The 1.5 s window lets the slicer see at least one
PREPARE push on the 1 Hz cycle so the transition reads as
PREPARE -> FINISH, matching what the slicer expects. Proxy mode is
exempt -- there the real printer drives the bridge state and a
synthetic FINISH would clobber a real PREPARE/RUNNING transition.
The scheduler cancels any in-flight timer when a new project_file
arrives so a retrying slicer doesn't end with two competing FINISH
timers. The pending timer is also cancelled on stop_server.
Non-proxy VPs (Archive / Review / Queue) with a target printer set up
a live-mirror bridge that forwards the slicer's MQTT and RTSPS auth
bytes through to the real printer. The slicer holds one code in its
profile (the one it bound the VP with), and that code has to satisfy
both the VP listener and the real printer at the far end of the
bridge. If the codes diverge the bridge silently fails at the second
hop — slicer reaches .49:8883, FINs before sending a ClientHello,
retries identically. The wiki framed the code-match requirement as a
camera-only concern; it isn't, all bridged protocols inherit.
Fix removes the foot-gun instead of re-documenting it. When a target
is selected on a non-proxy VP the access-code field switches to a
read-only display showing the target's code with an Eye-toggle
reveal; the backend auto-inherits on every create / update (any
explicit access_code submitted alongside a target is silently
overridden as belt-and-braces for non-UI clients). The required-when-
enabling check now treats target-set as satisfying the access-code
requirement. Standalone (no-target) non-proxy VPs still get the
editable input + Save button.
One-shot startup migration corrects any pre-existing mismatched
rows: SELECTs diverged VPs and logs one INFO line per row for the
audit trail, then UPDATEs via correlated subquery. Idempotent and
portable between SQLite and Postgres.
Bambu's end-gcode lowers the bed at gcode_state=FINISH. Bambuddy's
live-camera grab captured the bed already dropped, ruining the photo
framing. Source the photo from a brief Bambu timelapse instead —
firmware stops timelapse recording AFTER toolhead parks but BEFORE
bed-drop runs, so the last frame frames the finished print correctly.
When capture_finish_photo is on AND the user did not opt in to
timelapse for this print, force timelapse=True at dispatch + mark the
new PrintArchive.bambuddy_forced_timelapse column. After extraction
(success or failure), cleanup deletes the locally-attached file,
clears archive.timelapse_path, and walks the four scanner directories
(/timelapse, /timelapse/video, /record, /recording) trying FTP DELE
against the original filename. User-opted-in timelapses pass through
unchanged.
Resolver lives at services/background_dispatch.py::resolve_effective_timelapse
(module-level so the print queue can reuse it). Both dispatch paths
wired: background_dispatch.py (Print Now / Reprint) AND
print_scheduler.py:_start_print (the queue). Field testing caught the
scheduler gap on the first round — AST regression test now asserts
start_print(timelapse=...) references effective_timelapse, not the raw
item.timelapse, so a future refactor can't silently drop it.
Extractor: ffmpeg -i input.mp4 -update 1 -q:v 2 out.jpg. Decoded
frames overwrite the same output file, so the file left on disk is the
literal last frame regardless of duration. Bambu records one frame per
layer-change, so a 16-layer cube produces a 0.6 s timelapse — the
original -sseof -1.0 approach seeked before the start of the file and
returned frame 0 (empty bed). Decoding every frame is fine; Bambu
timelapses are short by construction even on hours-long prints.
Migration adds bambuddy_forced_timelapse branched on is_sqlite()
(DEFAULT 0 / DEFAULT FALSE — PG rejects DEFAULT 0 for BOOLEAN).
Verified live on postgres:16-alpine.
Photo-task wait_for budget extends 45s -> 75s when timelapse_was_active
so the notification carries the bed-up photo instead of falling back
to the live-cam grab on slow links.
Scope limit, documented in the camera wiki: prints started directly
on the printer touchscreen / Bambu Handy / Bambu Studio Send bypass
both dispatch paths, so the override doesn't fire there. Future
option: mid-print M981 S1 P20000 MQTT toggle in on_print_start.
Setting description rewritten in all 11 locales to drop the "only
works when timelapse enabled" caveat (Bambuddy now forces it) and
explain the kept-or-deleted behaviour.
SSDP multicast (239.255.255.250:2021) doesn't traverse routers, so a
printer behind a router on a different L3 segment was invisible to
"Discover Printers on Network". Docker mode had a CIDR text input but
only as a fallback when zero interface subnets were detected; native
mode had no subnet field at all.
AddPrinterModal now surfaces an always-visible subnet picker. Detected
interface subnets stay as dropdown options, plus a "Custom subnet..."
sentinel reveals a CIDR text input. When custom is picked, discovery
routes through POST /discovery/scan with the typed CIDR instead of
SSDP (which would no-op against a foreign subnet anyway). Last custom
CIDR persisted to localStorage so VLAN users don't retype every time.
Scan button label and scanning / no-printers-found strings all key off
(isDocker || useCustomSubnet) so wording stays "Scan Subnet..." /
"Scanning subnet..." whether the user is on Docker or just picked
Custom.
Backend unchanged: SubnetScanner.scan_subnet() already accepts any
CIDR, already caps at /22 (1024 hosts), POST /discovery/scan already
takes user-supplied input.
Reporter on a 1508x831 Pi display couldn't mark a project as Completed
because the edit modal's height exceeded the viewport: the outer wrapper
centers vertically and the inner card had no max-h and no overflow, so
the top half scrolled above and the bottom half (Status dropdown +
Save/Cancel) scrolled below. Workaround was a full page reload.
Standard flex-modal-scroll fix: max-h-[calc(100vh-2rem)] + flex flex-col
on the card; a flex-1 overflow-y-auto min-h-0 wrapper around the form
fields; Cancel/Save moved into a flex-shrink-0 sibling with a border-t
separator so they're always visible regardless of scroll position.
Buttons stay inside <form> so type="submit" still works.
Reporter linked a NAS and the auto-imported files drowned their own
Bambuddy uploads in the "All Files" sidebar listing. There was no filter
to escape it — only per-folder clicks. Restore the pre-external semantics:
"All Files" now lists managed-storage files only. The combined
across-every-external view moves to a new sibling sidebar entry,
"External", that only appears when at least one external folder is linked.
Backend: GET /api/v1/library/files gains internal_only and external_only
query flags. Filter is on LibraryFile.is_external. Both flags set is a
400, not a silent pick-one.
Frontend: new topLevelView state on FileManagerPage (default internal);
the query passes the scope only when selectedFolderId is null. Mobile
selector dropdown uses __top:internal / __top:external sentinels so the
same state round-trips through option values. Empty-state copy
distinguishes internal-empty from external-empty.
Printers added to Bambuddy by hostname/FQDN (e.g. p1s.fritz.box) hit
'invalid IPv4' in _ip_to_uint32_le, so the net.info[*].ip rewrite never
armed and BambuStudio Send went straight to the real printer instead of
the Bambuddy archive whenever the printer was powered on.
Add _resolve_target_to_ipv4(target): IPv4 pass-through, else
socket.getaddrinfo(target, family=AF_INET). AF_INET filter is load-bearing
because net.info[*].ip is uint32 LE and IPv6 can't round-trip. OSError
returns None so a transient DNS failure recovers on the next 30s refresh
tick via the existing not-armed throttle.
Apply the resolver to both the encode call and the host-interface picker
(which also assumes dotted-quad). Armed log line now carries
configured->resolved when they differ, so bad-DNS regressions stay legible
in 'docker logs'. The unresolvable not-armed reason now names the
configured value rather than parroting 'invalid IPv4', distinguishing
'DNS gave a v6 result' from 'user typed garbage'.
Root-caused by @Mape6; @TrickShotMLG02 confirmed the FQDN workaround
on the same release. Pre-0.2.4 these setups worked by accident because
there was no net.info[].ip rewrite at all.
Reporter @TheFou (on Docker bridge mode with the default userland-proxy:
true) saw ~2000 docker-proxy host processes spawn from the commented
"50000-51000:50000-51000" line, pinning ~3.5 GB of host RAM before they
had even logged in for the first time. The processes are host-level so
they don't appear in `docker stats`, which makes the leak invisible.
Linux's host-mode default in the same compose file sidesteps this
entirely (zero docker-proxy cost) - the issue only fires when a user
forces bridge mode (typically Docker Desktop on macOS / Windows).
The 1001-port FTP passive range is load-bearing on the VP server side
(virtual_printer/ftp_server.py:567-574 documents the widening from 100
ports as multi-VP collision-avoidance headroom against birthday-style
collisions when bind_ip=0.0.0.0). Reverting it would regress multi-VP
installs to solve a problem that only exists for bridge-mode users.
Fix is documentation, not code. Added a warning block above the
commented FTP-passive line pointing bridge-mode users at
{ "userland-proxy": false } in /etc/docker/daemon.json. Reporter
confirmed this clears the issue on their setup - the kernel does NAT
directly via iptables/nftables in that mode, no per-port host process
needed. Only side-effect is that connections originating from
127.0.0.1 on the host itself can't reach the container, which doesn't
matter for nearly every Bambuddy install.
Reported and root-caused by @needo37. Importing a model via the MakerWorld
URL-download feature into a writable external folder (e.g. SMB/NFS-mounted
NAS) saved the 3MF into Bambuddy's internal managed library dir, not the
external mount. The file card showed in the File Manager under the
external folder, but the bytes never landed on the NAS, and the on-disk
copy was UUID-renamed so a find by the original basename matched nothing.
Root cause was save_3mf_bytes_to_library at backend/app/api/routes/library.py:422:
it accepted folder_id but never loaded the folder, never inspected
is_external / external_path, hardcoded the destination to
get_library_files_dir() with a UUID name, and left the LibraryFile row
with is_external=False. So the row's folder_id pointed at the external
folder while its bytes and is_external flag both said "managed/internal".
Same class of bug as #1112, which had been fixed for the multipart-upload
and move paths but never applied to this byte-import path.
Fix mirrors the multipart-upload path directly:
- Load target_folder from folder_id when non-None.
- Feed it to _resolve_upload_destination(target_folder, filename), which
already returns (dest, is_external) and enforces the 403-read-only /
400-unwritable-or-missing / 409-collision rejections.
- Write bytes to dest (real filename for external, UUID for managed).
- Persist the row with file_path=_stored_file_path(dest, is_external)
and is_external=is_external.
The route-layer read-only guard at makerworld.py:256-260 is preserved -
it returns the friendlier error before the upstream download burns
bandwidth - and _resolve_upload_destination's identical check stays as
defence-in-depth for any future caller that skips the route gate.
Thumbnails continue to live under the managed get_library_thumbnails_dir()
regardless of the 3MF's location, matching the upload path.
The old endpoint name implied that calling it would drop weight_used to
0. In practice it only stamps weight_used_baseline = weight_used so the
Inventory page's "Total Consumed" widget (weight_used - baseline) reads
0 going forward, while remaining (label_weight - weight_used) is
preserved. Calling the endpoint via curl and seeing weight_used
unchanged in the JSON response is confusing.
New paths:
- internal: /api/v1/inventory/spools/{id}/reset-consumed-counter
/api/v1/inventory/spools/reset-consumed-counter-bulk
- spoolman: /api/v1/spoolman/inventory/spools/{id}/reset-consumed-counter
/api/v1/spoolman/inventory/spools/reset-consumed-counter-bulk
Behaviour is unchanged in both modes; internal stamps the baseline
directly, Spoolman-mode PATCHes upstream used_weight=0 and the
_map_spoolman_spool read mapping reconstructs the same "displayed
consumed = 0, remaining unchanged" Bambuddy-visible shape. Parity
between modes was already in place and is preserved.
The Spoolman-client method reset_spool_usage keeps its name because it
describes what is sent upstream to Spoolman, not what Bambuddy's
endpoint promises to callers.
Frontend:
- api.resetSpoolUsage / bulkResetSpoolUsage (and Spoolman variants)
renamed to resetSpoolConsumedCounter / bulkResetSpoolConsumedCounter.
- Button labels: "Reset usage to 0" -> "Reset counter" / "Reset all
counters" (short, unambiguous); tooltips and confirm-modal bodies
still spell out the full semantics.
Reporter @vasmarfas saw X2D archive cards land almost empty - only print
time, no filament weight / layers / MakerWorld link / thumbnail - and
Spoolman filament-usage tracking went silent on the same printer.
Support bundle traces the end-to-end: at print start
backend/app/main.py::on_print_start tries the usual FTP-download dance
for the 3MF, every implicit-FTPS connect attempt to the X2D fails with
`[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1032)`, ~2
minutes later "Could not find 3MF file for print" -> "Created fallback
archive". Fallback path writes file_path="", file_size=0,
content_hash=NULL, no layers / filament / model-link fields. Spoolman
tracking degrades from the same root cause - both depend on the 3MF
metadata parser.
Proximate cause: Python 3.13's default ssl.create_default_context()
negotiates TLS 1.3, the X2D's implicit-FTPS server on port 990 rejects
the ClientHello. Same family as the P2S 01.02.00.00 bug from #1401
(post-Python-3.13 TLS-1.3 breakage), different wire-level failure mode
(P2S completes the handshake and truncates with 426; X2D fails the
handshake outright).
Same fix shape: add X2D to backend/app/services/ftp_profiles.py with
cap_tls_v1_2=True, plus N6 -> X2D SSDP alias. Every other model stays
on negotiated TLS 1.3.
Honest caveat: hypothesis-driven trial, not a confirmed root-cause fix.
WRONG_VERSION_NUMBER could equally describe the X2D switching to
explicit FTPS (AUTH TLS on plaintext greeting) or moving FTPS to a
different port - either would need a different code path. Reporter has
been asked to test this build; if the cap doesn't clear it the registry
slot stays useful and the next diagnostic round goes to openssl
s_client from a network-adjacent host.
The hourly AMS sensor recorder dispatched humidity and temperature alarms
for every unit above threshold without checking whether the unit was
actually loaded. Empty AMS units still report ambient readings, so users
with one loaded + one empty AMS got useful alarms for the loaded one and
hourly noise for the empty one. Disabling the whole alarm category killed
both — not a real choice.
New _ams_has_filament helper inspects tray_exist_bits (hex bitmap, "0" =
empty) with fallback to the tray array's tray_type strings for shapes
where the bitmap is missing. The recorder gates the alarm dispatch on
this check per-AMS-unit, so a multi-AMS printer with one loaded + one
empty still alarms on the loaded one.
Sensor history still records regardless of the gate so the System page
humidity charts stay continuous — only the outbound notification is
suppressed. 9 unit tests cover the bitmap-zero case, bitmap-missing
fallback, garbage/blank/int bitmap edges, and defensive malformed tray.
_refresh_ip_encoding had 4 silent early-returns. When the rewrite
silently no-op'd on a user's setup, the only signal was the absence of
the "armed" INFO line, and diagnosing which path was firing meant
grepping the source.
Each path now emits one INFO line naming the specific reason. A
_not_armed_reason dedup field throttles to one line per state change,
so an idle unarmed bridge doesn't spam every 30s refresh tick. Cleared
on successful arm so regressions re-emit.
Not a fix for #1429 itself — the bridge logic is unchanged; this just
turns the silent failure into visible signal so the next "fix didn't
work for me" report can be triaged in one round-trip.
window.open(url, '_blank', 'noopener,noreferrer') returns null even on
success per the WindowFeatures spec — `noopener` deliberately suppresses
the return reference. The label-print modal treated null as "popup
blocked → fall back to <a download> click", so the fallback fired on
every click. Result: window.open opened the blob tab (downloading a
random-named PDF on systems without an inline viewer) AND the fallback
downloaded bambuddy-labels.pdf — two identical PDFs per click.
Drop noopener,noreferrer. The blob is same-origin, the destination is a
passive PDF preview tab with no script context, and noreferrer is no-op
for blob URLs. window.open now returns a real window reference on
success and the if (!win) fallback only fires on genuine popup-block.
H2C was in _DRYING_UNSUPPORTED_MODELS. Move to _DRYING_MIN_FIRMWARE
with the same 01.02.00.00 floor as H2S / P2S. Both SSDP model codes
the H2C advertises (O1C single-nozzle, O1C2 dual-nozzle) get the
same gate so supports_drying() fires correctly regardless of which
form is stored on the printer record.
The existing connection diagnostic proved TCP + TLS + auth + SUBSCRIBE but
not that the printer was actually publishing reports. A wrong-cased serial
passes mqtt_auth because the broker accepts the subscription regardless;
the user-visible symptom is empty AMS / no K-profiles / no custom filaments
in the slicer Device tab because the VP cached state is empty. Bambuddy
already logged the actionable hint at bambu_mqtt.py:498 but only to
container logs.
New printer_publishing check turns that warning into a structured
diagnostic result. Pass = bridge has seen at least one report since the
last (re)connect; fail = zero reports across the wait window with fix-text
pointing at the case-sensitive serial. Bounded 10s poll on the on-demand
UI route, no wait on the support-package gathering path so bundling stays
fast. Exits the moment a message arrives — typical wall-clock is 1-2s.
Frontend renders an elapsed-seconds counter plus a "Listening for status
report — up to 10s" hint during the pending state so the wait doesn't look
hung. PUBLISH_WAIT_DEFAULT_SECONDS pinned on both sides.
report_messages_since_connect exposed as a public property on
BambuMQTTClient so the diagnostic doesn't reach into private state.
The Scheduled Local Backups time-of-day picker was interpreted as UTC by
_calculate_next_run, so a UTC+3 user had to enter 18:00 to get a 21:00
local backup. The UI labeled the field "UTC" but it was still surprising.
Picker is now interpreted in the container's local timezone, resolved
from the TZ env var via zoneinfo.ZoneInfo (same source the Support page's
environment.timezone shows). UTC fallback when TZ is unset or
unrecognised. The /local-backup/status endpoint exposes the resolved
zone, and the UI renders it next to the field via a new
backup.localTimeHint i18n key with real translations in all 10
non-English locales.
One-time behaviour change for users who entered a UTC time as a
workaround: the first scheduled cycle after upgrade will run at their
local TZ offset earlier than expected. Re-enter the time as local once
and it is correct from then on. No migration is shipped; migrating
around a DST boundary would be ambiguous.
ESLint no-useless-escape flagged 156 errors (153 in ko.ts, 3 in tr.ts):
\" inside single-quoted Korean strings and \' inside double-quoted
Turkish strings. The escapes weren't needed because the surrounding
quote style differs from the escaped quote. Visible-text unchanged;
i18n parity green at 5007 leaves × 10 locales.
pip-audit flagged four advisories against 2.12.1, all fixed in 2.13.0.
Audited the five behavioural changes in 2.13.0 against our usage; none
apply (HMAC empty-key reject can't trigger, OIDC decode uses raw-key
path not PyJWK, jwks_uri is HTTPS from discovery, no b64=false usage,
enforce_minimum_key_length not opted into). 229 auth/MFA/OIDC
integration tests + 78 auth unit tests green on 2.13.0; runtime
encode/decode roundtrip verified with the real SECRET_KEY; pip-audit
--strict now clean.
Four frontend formatDate / formatDateTime helpers called new Date(iso)
directly on backend timestamps that have no timezone indicator. Per
ECMAScript, a bare "2026-06-02T07:50:00" is parsed as local time, so
a UTC-stored value got displayed as if its numeric components were
already local — visually identical to UTC. Same shape as the #504
fix from Feb 2026, which patched 13 sites but missed these four:
PrintLogTable and SpoolUsageHistory hadn't been written yet;
CameraTokensPage and SpoolBuddySettingsPage existed but were
overlooked.
Reporter #2 (@IndividualGhost1905) confirmed with a UTC+3 host: print
log shows UTC clock value, system date shows local. PrintLogTable is
the "logs/completion time" they called out; the other three are the
same pattern in nearby surfaces.
Replaced the bare new Date(iso) calls with parseUTCDate(iso) from
utils/date.ts — the same helper every other date formatter in the
codebase already uses. It appends "Z" to naive ISO strings and
parses TZ-tagged strings as-is. CameraTokensPage.isExpired got the
same fix because comparing a misparsed Date against Date.now() would
produce false "not expired" / "expired" results around the TZ-offset
boundary.
Reporter #1's printer-card ETA complaint (10:50 + 57m showing 09:48)
is NOT addressed by this fix. That ETA comes from
formatETA(remainingMinutes) which is purely client-side (new Date()
plus minutes from the WebSocket payload, then toLocaleTimeString)
— for it to render UTC the browser timezone itself would need to
be UTC, which is a browser / OS config issue.
Audit confirmed no other regressions: grepped every new Date( call
in frontend/src/. Remaining sites either pass an epoch-ms number,
use the result only for .getTime() arithmetic where the offset
cancels, already wrap in parseUTCDate fallback, or consume a
backend timestamp that includes "+00:00" (FailureDetectionSettings
reads obico_detection.py's tz-aware isoformat).
compute_time_accuracy in routes/archives.py compares the archive row's
own started_at / completed_at (which reflect the latest run only)
against archive.print_time_seconds (which the #1593 parser fix
correctly stores as the sum across plates). For a 3-plate file printed
plate-by-plate the ratio is ~300%, producing a "+188%" card badge that
means nothing — apples to oranges. The 5-500% sanity band catches
truly broken values but lets this deterministic N×100% shape through.
Reporter's archive #65 was 3 plates over 9 runs.
compute_time_accuracy gains an optional run_aggregate argument and
returns both actual_time_seconds and time_accuracy as null when the
aggregate reports more than one logged run. The frontend already falls
through to print_time_seconds for the time display
(actual_time_seconds || print_time_seconds) and gates the badge on
time_accuracy being truthy, so multi-run archives now show the slicer
estimate with no badge. Single-run archives keep the original
behaviour verbatim.
The fix is applied at every call site that renders an archive card:
archive_to_response now threads run_aggregate through, and the three
endpoints that previously didn't load the aggregate (archives.py
search fast-path and FTS path, single-archive PATCH, and
projects.list_project_archives) now batch-load it via the existing
_load_run_aggregates helper.
The stats endpoint's per-run accuracy aggregation at archives.py:940
already uses PrintLogEntry.duration_seconds with its own 50-200% band
filter and is untouched.
The #620 patch fixed the OpenSSL-3.x-strips-plain-RSA-AES-GCM cipher
mismatch on the printer-facing TLSProxy client context. The same fix
was never applied to the four other slicer-facing TLS contexts. On
hardened distros (Fedora / RHEL with update-crypto-policies, hardened
Alpine builds) where the system narrows DEFAULT to forward-secrecy
only, the slicer's ClientHello finds no overlap with what Bambuddy
offers and the handshake aborts with the slicer reporting code=-1
before any application data flows. The reporter pinpointed the missing
set_ciphers call in bind_server.py against the #620 lineage; the
audit-wide sweep here extends the same fix to mqtt_server.py,
tcp_proxy._create_server_ssl_context (the missing other half of #620),
and ftp_server.py.
For the three new contexts (bind / mqtt / proxy-server) the cipher
string is DEFAULT:AES256-GCM-SHA384:AES128-GCM-SHA256 — verbatim match
with the #620 client-side fix. For FTPS the original HIGH baseline is
kept (HIGH:AES256-GCM-SHA384:AES128-GCM-SHA256:!aNULL:!MD5:!RC4) so the
cipher set stays a strict superset of what shipped before — HIGH
offers ~58 suites DEFAULT doesn't (CCM / ARIA / CAMELLIA / DSS) that
no Bambu slicer is known to pick, but narrowing a compat surface
without proof would violate the existing don't-remove-compat-pinning
rule. TLS version pins (TLSv1_2 minimum across all four, TLSv1_2 max
on FTPS for the BambuStudio PSK-reuse compat) and verify-mode settings
are unchanged — only the cipher list is widened.
When no explicit slot-to-tray mapping is captured (path 5 of 6 in
_track_from_3mf — fires before the request-topic subscription that catches
ams_mapping is accepted), the tracker builds available_trays from
build_ams_tray_lookup and uses position to map the slicer's Nth filament
to the Nth available tray. The helper enumerated every AMS tray by id
regardless of whether a spool was loaded, so AMS slots 0-2 loaded + slot 3
empty + external yielded available_trays = [0, 1, 2, 3, 254]. The slicer
compacts its filament UI to hide empty AMS slots, so its 4th filament is
the external — but position mapping routed it to AMS0-T3 (the empty slot)
instead of 254 (external). No spool assigned there → usage silently
skipped → external never decremented.
Filter the fallback to slots with a non-empty tray_type. build_ams_tray_lookup
stays unchanged for its other callers (spoolman_tracking.store_print_data,
routes/printers, spool_assignment_notifications); the filter is applied at
the usage-tracker call site only. Mirrors the existing vt_tray filter in
build_ams_tray_lookup line 174.
The original #1429 fix's _refresh_ip_encoding early-returned when
mqtt_server.bind_address was "0.0.0.0" or empty (the default for VPs created
without a dedicated bind IP). On a flat-LAN install that's the typical case,
so the encoding never armed, _rewrite_net_info_ips was a no-op on every push,
and the slicer kept following the real printer IP to its SD card. @Mape6
reported this on the 2026-06-02 daily that supposedly fixed the bug.
New helper _resolve_host_interface_for_target() consults the existing
network_utils.find_interface_for_ip() to pick the host interface in the
printer's subnet. _refresh_ip_encoding falls back to it when bind_address
is unspecified; an explicit bind IP still wins. INFO log line distinguishes
the two paths ("armed: ... (bind_address)" vs "(auto-resolved)") so future
bundles directly answer which IP the rewrite picked.
Tests: 4 new under TestBindAddressAutoResolve — rewrite arms via auto-resolved
IP at bind_address=0.0.0.0; stays disabled if no interface matches (no crash);
explicit bind_ip still takes precedence; helper returns None defensively when
find_interface_for_ip does.
maziggy