Closed claudermilk closed 5 months ago
This appears to be an issue with the frontend. Based on the error in your issue, the frontend is requesting metadata for a file named filename.gcode
. I would presume that this is not the actual file name, and instead is a placeholder.
I stuck in "filename" as a placeholder (it was long). The log file has the actual file name in it, sorry for causing the confusion.
Please attach the full log.
This is a known issue, but I don't think it's being actively tracked in the fluidd repo yet. So far I haven't been able to reproduce this, the only times I saw this myself was when a file was deleted or moved and the entry in the reprint tab on the dashboard hadn't been updated yet (but then starting the print would fail too).
@Arksine As I think this isn't a moonraker issue, feel free to close this - I'll open an issue in the fluidd repo then.
OK, I'll close this and open a bug report on Fluidd. I kind of knew whichever of Klipper/Moonraker/Fluidd I tried to identify as the culprit, I'd pick wrong.
Ok. FWIW, I don't mind looking at the log to see if it provides some context which can help narrow down the issue. If that isn't fruitful you could try to reproduce with verbose logging enabled, as we could see the exact sequence of events that led to the metadata error.
Conveniently, one of the printers immediately threw the error this morning. I've also mentioned on a similar issue over at the Fluidd project. moonraker.log
I see the error, unfortunately without verbose logging enabled there isn't much context. I presume that it occurred after starting a print? There is an upload of the same file about 13 seconds after the metadata error, was the intent here to overwrite the file to force metadata extraction?
FWIW, you can enable verbose logging by adding the following to /home/pi/printer_data/systemd/moonraker.env
:
MOONRAKER_VERBOSE_LOGGING="y"
That said, it will create large log files, so you will want to disable it after reproducing the error.
Tagging fluidd-core/fluidd#1408, the issue is now tracked there.
What happened
Sometimes when starting a print job, after selecting a spool for the Spoolman integration the error message "The amount of filament required to print the selected file is unknown. Do you wish to continue?" is displayed.
Client
Fluidd
Browser
Chrome
How to reproduce
After a print job is completed, start another one. It's intermittent, so no telling when it throws the error.
Additional information
Issuing a firmware_restart clears the issue. I have seen this on two different printer installations; one just got a complete software and firmware re-install. I have seen this since the Spoolman integration was introduced. Running on RPi Debian Lite on both a RPi 3A+ and 4. Spoolman is a standalone server currently running the current 0.16 (was 0.13--same behavior).
The relevant log error line is: [common.py:build_error()] - JSON-RPC Request Error - Requested Method: server.files.metadata, Code: -32601, Message: Metadata not available for