Custom-filament spools are permanently "Unsupported": AddEditDialog writes a preset setting_id into a field matched against filament_id

[marciogranzotto]

Version: 02.08.02.61 (Windows)

Summary

Spools added via Filament Manager for a custom filament (any vendor not in Bambu's global
cloud catalogue) are written with an id from the wrong namespace, so they can never resolve and
are shown under Unsupported Filaments forever.

On my install this affected 13 of 35 spools.

Root cause

The reader accepts only a filament_id. PresetBundle::get_filament_by_filament_id
(src/libslic3r/PresetBundle.cpp) matches:

if (filament_preset.filament_id == filament_id) { ... }

and AMSMaterialsSetting.cpp:1557 feeds it the spool's setting_id:

bool has_preset = bundle && bundle->get_filament_by_filament_id(sp->setting_id).has_value();
if (has_preset) { lib_brand_to_spools[brand].push_back(*sp); }
else            { unsupported_spools.push_back(*sp); }

The writer picks that value with this precedence
(.../device_page/src/features/filament-manager/AddEditDialog.tsx:1092, mirrored at :528):

setting_id: matchedCloudFilamentId
  || matchedPresetItem?.setting_id     // <-- wrong namespace
  || matchedPresetItem?.filament_id
  || initSpool?.setting_id
  || '',

matchedCloudFilamentId resolves only on an exact match against the global cloud
catalogue:

settings.find((it) => it.filamentVendor === brand && getCloudSettingDisplayName(it) === name)

A user's own custom filament is never in that catalogue, so the first term is empty and the
code falls through to matchedPresetItem?.setting_id. Preset setting_ids are PFUS + 14 hex,
while filament_ids are P + 7 hex (or GFxxx) — so the stored value can never equal any
preset's filament_id.

Concretely, from the config/fetched payload on my machine the catalogue has 99 entries:
Bambu Lab (49), Generic (29), Polymaker (11), SUNLU (7), Overture (2), eSUN (1 — PLA+ only).
Zero Voolt3D.

Evidence

Every broken spool held a PFUS… value that is the setting_id of the very preset it should
have pointed at:

filament	stored	should be
Voolt3D PLA Velvet ×7	PFUSe33e0b6500d7db	P1115d06
Voolt3D PLA V-Silk ×3	PFUS1f80b571b870da	Pfb40f61
Voolt3D PLA Cosmos ×1	PFUSea8b1450d8fde2	P79667af
eSUN PLA Silk ×1	PFUS305ecd90345eb2	Pf004bc9
eSUN PLA Basic ×1	PFUS6d82e386f81e4b	Pa699948

The same filament appears in both states — PLA Velvet OK on 6 spools / broken on 7, V-Silk
OK on 2 / broken on 3 — confirming this is per-spool write data, not a preset problem. The
healthy ones were created earlier, via a path that resolved the real filament_id.

Why the middle term looks safe to remove

In the preset/list payload on my install, all 325 preset items carry both filament_id and
setting_id — 0 items have setting_id without filament_id. So the
matchedPresetItem?.setting_id term can never act as a useful fallback: whenever it is
non-empty, filament_id is non-empty too. It can only shadow the correct value.

(This is one machine's data — maintainers should confirm there is no profile source where an
item legitimately has setting_id but no filament_id.)

Suggested fix

Drop the wrong-namespace term, or at minimum order it last, at both sites
(AddEditDialog.tsx:1092 and :528):

   setting_id: matchedCloudFilamentId
-    || matchedPresetItem?.setting_id
     || matchedPresetItem?.filament_id
     || initSpool?.setting_id
     || '',

Reproduce

1. Create a custom filament preset for a vendor absent from the cloud catalogue (e.g. "Voolt3D").
2. Filament Manager → Add Filament → pick that brand/filament → save.
3. Open any AMS slot → Materials Setting → the new spool is under Unsupported Filaments.
4. Its stored id is the preset's PFUS… setting_id rather than its P… filament_id.

Re-picking the filament in the dialog does not fix it — it re-runs the same fallback and
writes the same wrong value.

Note

pull_from_cloud calls list_spools with an empty query and never paginates
(FilamentQueryParams defaults limit = 20). I did not reproduce truncation — all 35 of my
spools were returned — so either the limit isn't transmitted or the server default is higher.
Flagging it only as something worth a look, not as an observed bug.

[marciogranzotto]

Closing this as a duplicate — I should have searched before filing, apologies for the noise.

The same problem is already tracked in #11937 (and reported in #11562, #11654, #11871), and @JaKuBisz had already identified the same root cause and opened #12060, which goes further than this report: a Generic <type> fallback for free-typed brands, a one-time migration that backfills the broken setting_id on existing manual spools, and the remaining-weight fix.

Two data points from this investigation that may still be useful, moved here for the record:

1. Every preset item carries both ids. In the preset/list bridge payload on my install, all 325 items have both filament_id and setting_id — zero have setting_id without filament_id. So matchedPresetItem?.setting_id can never act as a useful fallback; whenever it is set, filament_id is set too. It can only shadow the correct value. (Fix third-party filaments unusable in AMS + remaining weight never updating (#11937) #12060 orders it last rather than removing it, which is the conservative choice and fine.)

2. The same filament appears in both states, which rules out a preset-side cause. On my install, Voolt3D PLA Velvet was healthy on 6 spools and broken on 7; PLA V-Silk healthy on 2, broken on 3. Broken spools were created 10–28 Aug, healthy ones earlier — consistent with a regression in the write path rather than anything wrong with the presets.

For anyone hitting this before a fix ships: the repair is to rewrite each affected spool's setting_id from the preset setting_id (PFUS + 14 hex) to that preset's filament_id (P + 7 hex). Re-picking the filament in the dialog does not work — it re-runs the same fallback and writes the same wrong value.

#12079 is left open as a minimal one-file variant, but #12060 is the more complete fix and should take precedence.