Randomly .gcode files that where uploaded via OctoPrint cant be moved to sub folders.
Some work, some don't... I cant seem to make out wether its formatting problem of the file
name or anything else. There are no unusual characters in the file name etc.
Latest Version 1.4.2
Note:Canceled prints that appear red, can not be moved in any case... green that had already printed
do work most of the times, but not all times.
Reloading the web interface has so far not made a difference.
I was unable to reproduce this, all files I try to move go successfully into their new folder, regardless of failed or successful prints.
There's a critical part missing from your post though, logs. There's a section in there that says this:
Have you tried running in safe mode and if so did it solve the issue?
WRITE HERE
Complete Logs
octoprint.log,serial.logor output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support! Not log excerpts, complete logs.)WRITE HERE
Additional information about your setup
OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible
WRITE HERE
It would help loads if you were to fill this out.
I did not try safe mode... the printer is printing at the moment.
I am running on OctoPrint Version 1.4.2, with OctoDash installed on a Pi 4B with 5" Waveshare touch screen.
The issue happens via remote access from webbrowser over local WIFI Lan.
Printer Ender 3 V2, with currently stock firmware 1.0.2.
Browser OS X Mojave 10.14.6 / Safari 13.0.1
octoprint.log (2.9 MB) serial.log (148 Bytes)
right after trying to move a file, this lines are added to the log:
2020-10-24 22:07:04,834 - octoprint.util.comm - INFO - Changing monitoring state from "Starting" to "Printing"
2020-10-24 22:07:50,372 - tornado.access - WARNING - 409 POST /api/files/local/CE3_OctoBezel.gcode (::ffff:192.168.100.166) 18.36ms
2020-10-24 22:11:29,773 - octoprint.server.util.sockjs - INFO - Client connection closed: fe80::1845:fe59:f007:ade7
2020-10-24 22:19:14,092 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-10-24 22:28:25,038 - tornado.access - WARNING - 409 POST /api/files/local/CE3_OctoBezel.gcode (::ffff:192.168.100.166) 29.72ms
So the reason this seems to be happening is because the file is being used for something else.
First, there is the OctoPrint analysis that runs right after you upload the file, but this does not happen until there is no print. So it looks the moving of the file fails while you have the print started, since it hasn't analysed the file yet. (and is still in the queue)
Then there is the times when Display Layer progress is processing the file, that seems to block it as well. This happens when you select a file, iirc.
My suggestion is to try this when the printer is not printing, and also in safe mode, since it seems DPL is conflicting sometimes.
I tried briefly this morning, moving files, after print had completed, restarted Pi etc... the problem of the very same file resists.
One thing I can think off is, I uploaded most files via Cura. When doing this while a print is running, Cura gives a warning message that the file could not be added as active print job (some message along those lines).
As you mentioned OctoPi will run some validation on the file, but might be interrupted by this Cura vs. Printer busy state. Hence it might affect some files and the ones that go directly into printing not.
I need to pa closer attention which file was added which way to draw a conclusion.