Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Error in octoprint.log from "delete_old_unrendered_timelapses" in timelapse.py #1326

Closed
ScottWell1 opened this issue May 5, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@ScottWell1
Copy link

commented May 5, 2016

What were you doing?

Rendering a timelapse. Repeatable (happens with every timelapse render). Render completes normally, timelapse is created successfully, and all snapshot files are deleted from the timelapse\tmp folder.

However, at the end of every timelapse render, errors are thrown (one for each snapshot file) into octoprint.log. The error message implicates the "delete_old_unrendered_timelapses" routine.

Example error below. The same sequence is logged for every snapshot file (i.e., if there are 500 snapshot files, there will be 500 of these errors logged).
----- octoprint.log excerpt -----
2016-05-05 04:02:43,676 - octoprint.timelapse - ERROR - Error while processing file extrusion_steps_mini_20160505033958-555.jpg during cleanup
Traceback (most recent call last):
File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.2.11-py2.7.egg/octoprint/timelapse.py", line 154, in delete_old_unrendered_timelapses
if os.path.getmtime(path) < cutoff:
File "/home/pi/oprint/lib/python2.7/genericpath.py", line 54, in getmtime
return os.stat(filename).st_mtime
OSError: [Errno 2] No such file or directory: '/home/pi/.octoprint/timelapse/tmp/extrusion_steps_mini_20160505033958-555.jpg'
---- end of log excerpt ----

What did you expect to happen?

I expected the render to complete without any errors from the delete_old_unrendered_timelapses routine. Please note that there are no "old" timelapse files. The timelapse\tmp folder was empty prior to the print, snapshots were created during the print, the snapshots were rendered and deleted successfully at end of print.

What happened instead?

For each snapshot file in the current render, a "file not found" error was logged in octoprint.log.

Branch & Commit or Version of OctoPrint

OctoPrint 1.2.11 (master branch)
(Not new to this release -- problem occurred before update to 1.2.11).

Printer model & used firmware incl. version

Not printer or firmware specific. (Lulzbot Mini, Marlin 1.0.2)

Browser and Version of Browser, Operating System running Browser

Not a browser issue. (Chrome 50.0.2661.94 on Win7x64)

Link to octoprint.log

https://gist.github.com/ScottWell1/ee59a39c5b9748ec1762fbde9cffd0c2

Link to contents of terminal tab or serial.log

Not applicable.

Link to contents of Javascript console in the browser

Not applicable.

Screenshot(s) showing the problem:

Not applicable. See logs.

I have read the FAQ.
Yes. I am using Octopi, however it appears this error is within the Octoprint code.

foosel added a commit that referenced this issue Jun 2, 2016

Don't concurrently delete unrendered timelapses
Could trigger lots of errors if an unrendered timelapse currently
being collected was deleted from a separate thread from right
under the collection thread.

Also only log errors while processing already deleted files
if debug logging is enabled.

Finally trigger MovieDone event AFTER deleting unrendered
files (otherwise just rendered timelapse might still be present
when list of timelapses is queried right after).

Should solve #1326

@foosel foosel added this to the 1.2.12 milestone Jun 2, 2016

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 2, 2016

So... I haven't been able to reproduce this at all myself, but looking closely at the described symptoms I got an idea what might be causing this and fixed that.

I think the issue was that before deleting the image of a just rendered timelapse the frontend already got signaled that the rendering was done, prompting a new fetch of the timelapse list, including unrendered ones, which in turn triggered the cleanup task. Depending on the timing of things it could then happen that the cleanup task was still collecting information about the unrendered (but actually just rendered) timelapse of the current print job while at the same time in another thread that one was being deleted, leading to attempts to look at files that had since vanished. At least that's behaviour I can definitely confirm being possible looking at the code.

I now signal the frontend AFTER cleaning up the timelapse, added a lock to synchronize cleanup task and actual deletion code (so that one can't run while the other is already active) and on top of things made errors on deletion/cleanup only show up in the log in debug mode.

That should hopefully have solved this.

@foosel

This comment has been minimized.

Copy link
Owner

commented Jun 2, 2016

Solved on both devel and maintenance branch, will be part of the next release.

@foosel foosel closed this Jun 2, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.