User report: with 4 spools mapped, every print deducted the same
several-gram amount from ALL 4 spools regardless of which one was
actually printing with, adding up to ~150g of drift over time on an
unused spool.
Root cause: _spoolman_last_sync was reset to 0.0 (epoch) at print
start instead of the current time. The poll loop calls
_spoolman_sync_midprint() before _spoolman_attribute_tick() in the
same iteration, so with last_sync=0.0 the sync-due check was true on
the very first tick after print start - before any per-slot
attribution existed yet. _spoolman_unreported() then fell back to
splitting the printer's full (possibly already nonzero) supplies_usage
equally across every mapped spool, matching the reported log
(identical mm reported to all 4 spools, right after upload before the
purge even started).
Fixes:
- _on_print() now resets _spoolman_last_sync to time.time(), not 0.0,
so the first sync check is only due after a real interval has
passed with attribution data available.
- _spoolman_unreported()'s fallback now only applies with exactly one
mapped slot (single-extruder, no ambiguity) - with multiple slots
and no attribution data it reports nothing instead of guessing,
since a wrong equal-split is worse than a temporarily-missed report.
Added tests/test_spoolman_unreported.py covering both fixes.
(Same fix as testing branch commit b44c902, applied manually here
since nightly still has the pre-mixin-split monolithic
kobrax_moonraker_bridge.py layout - bridge_mqtt.py/bridge_spoolman.py
don't exist on this branch yet.)