OrcaSlicer files show "Slicer: Unknown" on the Creality K2 — a one-line fix

If you slice with OrcaSlicer and upload the file to a Creality K2 via Fluidd, the metadata column will say slicer: Unknown. Thumbnails are missing. The estimated print time is suspiciously round — usually 1h58m, 2h30m, that kind of thing — because Moonraker has fallen back to parsing the filename rather than reading the actual estimate from inside the file.

This is fixable in one line. Here's what's going on, what the patch does, and what it unlocks.

The symptom

Open Fluidd, look at the file list. For an OrcaSlicer-sliced job you'll see:

• Slicer: Unknown — should be OrcaSlicer 2.x.x
• Estimated time: a round number parsed from the filename — should be the slicer estimate
• Filament: empty — should be type, name, total grams
• Thumbnail: placeholder — should be the rendered preview
• Layer count and height: empty — should be populated
• First layer temps: empty — should be populated

The K2 still prints the file fine. You just get no preview and a misleading time estimate.

Why it happens

Moonraker has a metadata extraction component at /usr/share/moonraker/components/file_manager/metadata.py. Inside there's a PrusaSlicer class with a check_identity method that walks an aliases dict trying to match a regex against the slicer comment block at the top of a gcode file. The dict has entries for PrusaSlicer, SuperSlicer, BambuStudio… but not OrcaSlicer.

OrcaSlicer is a fork of PrusaSlicer (via BambuStudio), so all the parsing functions inside PrusaSlicer work correctly on Orca files. The only thing that's missing is identification. Without identification, Moonraker doesn't dispatch to that class, falls through to the generic handler, and ends up reporting Unknown with no fields populated.

The patch

SSH into the K2, edit metadata.py, find the aliases dict around line 322 — it has entries that look like 'PrusaSlicer': r"PrusaSlicer\s(.)\son", one per slicer. Add an OrcaSlicer entry following exactly the same pattern: the alias string is OrcaSlicer, the regex is OrcaSlicer\s(.)\son. That's it.

Save the file, restart Moonraker with /etc/init.d/moonraker restart. Re-upload an OrcaSlicer file (or trigger a re-scan from Fluidd's file manager — Moonraker only re-extracts metadata on upload, not on re-read). You should now see thumbnails, layer count, accurate print time, filament weight, first-layer temps — all the metadata Fluidd has always been able to display, it just couldn't access it before.

Why it works

Because OrcaSlicer is a PrusaSlicer fork, every extract_metadata() and parse_thumbnails() function written for PrusaSlicer's gcode format works unchanged on OrcaSlicer's output. The thumbnails are encoded the same way, the metadata comments are written in the same format. The only thing missing was the entry-point regex that lets Moonraker say "yes, I know this slicer."

Caveats

A few things worth knowing.

This patch will be overwritten if you reflash or update Moonraker. The K2 doesn't auto-update Moonraker, so in practice the fix sticks for a long time, but make a note. If you're worried, write a tiny shell script that re-applies the one line on boot.

Bambu Studio is also a PrusaSlicer fork, and it should already be handled in stock K2 Moonraker. If Bambu files also show Unknown on yours, your Moonraker may be older than I'm assuming.

Always back up metadata.py before editing. The convention I use is metadata.py.bak-orca-<unix-timestamp> written into the same directory. To revert, copy the backup back over the live file and restart Moonraker. (For the broader Creality K2 backup workflow, see What actually needs backing up on a Creality K2.)

Why hasn't Creality fixed this upstream?

Creality's K2 ships a snapshot of Moonraker that predates OrcaSlicer's wide adoption. Their Moonraker is forked-and-frozen, not pulling from upstream Moonraker master. There's no auto-update path on stock K2 firmware, so unless someone (Creality, or you) manually patches it, the gap stays.

This is the same pattern as the shaper_calibrate.py math gap I wrote about in Why your Creality K2's input shaper recommendation might be wrong — drift between the K2's snapshot and current upstream code. Most of these gaps are small and individually invisible until you hit them.

What's next

This single-line patch is going to ship as part of a planned K2 Quality-of-Life Patcher Windows tool — same model as my K2 Backup tool: drag, click, done. The patcher will hold a list of curated, reversible fixes (this OrcaSlicer one, the shaper math fixes, the Qmode_exit PA guard) and apply them with timestamped backups. Watch the Hark Tech tools page if that's useful.

If you're running OrcaSlicer on a K2 and you've already noticed the missing metadata, you now know the cause. Five minutes of SSH and you've got your thumbnails back.