mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-10-05 13:41:36 +02:00
Three Bambu Lab catalog rows share #FFFFFF — Jade White (PLA Basic), Ivory White (PLA Matte), White (PLA Silk). The catalog lookup in create_spool_from_tray filtered by manufacturer + hex only with no ORDER BY, so SQLite returned rows in rowid order and the first-inserted entry (Jade White) won every RFID-driven spool creation regardless of the actual material the AMS reported. Inserting an Ivory White PLA Matte roll always produced a spool named "Jade White". Same class of bug bites any other shared-hex pair across PLA Basic / Matte / Silk; the whites were just the most visible. Fix: add a material filter using tray_sub_brands (the printer-reported material variant — "PLA Matte" / "PLA Basic" / "PLA Silk"), which matches the catalog's `material` column directly. Use the raw tray_sub_brands value (captured before the gradient/dual/tri-color subtype upgrade) because the catalog stores "PLA Basic" for gradient rolls too — the upgraded subtype lives on the spool, not the catalog. Also add ORDER BY id to the query so the fallback path (empty tray_sub_brands — third-party spools / OpenTag tags) is deterministic across SQLite + PostgreSQL instead of DB-implementation-defined. Tests: 4 new in test_spool_tag_matcher.py — Ivory White PLA Matte resolves to Ivory not Jade (the regression pin), PLA Silk White resolves to White, Jade White PLA Basic still works with all three #FFFFFF entries seeded, and the empty-sub_brands fallback stays deterministic via the new ORDER BY. Existing spools already mis-named in the database don't auto-correct on next AMS read — the matcher only fires on new RFID-driven creation. Affected users need a manual rename in Inventory after upgrading.