mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-09-30 03:01:21 +02:00
maziggy
6fb6b845e7
A sliced file numbers its filaments 1..4; which AMS tray each came from is a separate decision made when the job is sent. store_print_data learns it from one of two sources, both of which require the print command to pass through us: the mapping Bambuddy chose itself, or the one it intercepted on the printer's local request topic. A job dispatched from Bambu Studio while the printer is cloud-bound satisfies neither -- the command travels through Bambu's broker and never reaches the topic we subscribe to. slot_to_tray is then NULL and _resolve_global_tray_id guesses by position: filament 1 from the first loaded tray, filament 2 from the second. The reporter's X1C was loaded in the order 2, 4, 1, AMS-HT, so all four slots were charged to the wrong spool. Their log carries the printer's own answer, mapping=[1, 3, 0, 32768], sitting unread. usage_tracker has consulted that field since it started resolving mappings at completion, along with a colour match against the loaded trays for the models that never publish it (A1, A1 Mini, P1S, P2S). Only the Spoolman writer, which resolves at print start, never learned to -- and main.py gates usage_tracker behind Spoolman being off, so enabling Spoolman is what costs you the better resolver. _resolve_slot_to_tray_fallback gives it both, at completion rather than at print start: a printer keeps publishing the last job's mapping while it sits idle, so reading it early would risk stamping the previous print's mapping onto this one. A mapping we or the slicer actually recorded is never second-guessed. Applied in _report_partial_usage too. Cancelled and failed prints feed the same slot_to_tray to the same resolver and mis-charged just as readily. The resolved mapping and its source are now logged at print start and at completion. "source: none" at start is the signal that completion will have to fall back, and it was the one line that would have turned this report into a five-minute triage. Not addressed: editing the mapping after the fact, which the reporter also asked for. ArchiveUpdate exposes neither filament field and there is no way to re-run an attribution, so that is a feature rather than a fix.