WARNING: UPGRADE TO 0.0.5 PREVIOUS WORKING IMAGES ARE BROKEN about octoprint-prusaslicerthumbnails

[jneilliii]

This might be possible, I'll see what I can do.

[blackbird042]

Would it be possible to crawl through already uploaded files and extract images from them (let's say as an option in settings)?

[mvasilakis]

On one of my octoprint it was working with 0.0.5 but stopped with 0.0.6. On the other, however, it's working just fine after the 0.0.5 > 0.0.6 upgrade. Can this be a related bug?

Checked all the profiles and they still have the correct "Thumbnail" info. Thumbnails are showing fine on the Mini Octoprint but not on the MK3s. Restarted PrusaSlicer, still no joy. :(

[jneilliii]

It could be. Either way, my fix should allow you to fix it. Just needs a little more testing.

[jneilliii]

If you guys would like to test, I've tried it in my development windows environment and on my production pi and it seems to work. If you were using a Prusa Mini in the past it will also in theory extract the thumbnails for those too. Use the URL below in Plugin Manager and after restarting OctoPrint make sure you force a refresh of the browser to overwrite any locally stored cache.

Once you're back up, in the plugin's settings there is a new button Crawl Files. I will probably change that name and tweak the layout of the results returned underneath the button, but functionally it should be fine. Press the button and you should get a list underneath once the process completes with additional information on what was seen.

https://github.com/jneilliii/OctoPrint-PrusaSlicerThumbnails/archive/0.0.7.zip

[blackbird042]

Great job. Crawling works, but only on my test environment. On production it starts and looks like manages to do some files, but finishes very quickly. Looking at log file, I would say that then problem is with nested folders.

2020-04-27 08:11:37,172 - octoprint.server.api - ERROR - Error while executing SimpleApiPlugin prusaslicerthumbnails
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/server/api/__init__.py", line 109, in pluginCommand
    response = api_plugin.on_api_command(command, data)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_prusaslicerthumbnails/__init__.py", line 121, in on_api_command
    results = self._process_gcode(LocalFiles[key], results)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_prusaslicerthumbnails/__init__.py", line 102, in _process_gcode
    self._process_gcode(children[key], results)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_prusaslicerthumbnails/__init__.py", line 94, in _process_gcode
    self.on_event("FileAdded", dict(path=gcode_file["path"],storage="local",type=["gcode"]))
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_prusaslicerthumbnails/__init__.py", line 79, in on_event
    self._extract_thumbnail(gcode_filename, thumbnail_filename)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_prusaslicerthumbnails/__init__.py", line 57, in _extract_thumbnail
    with open(gcode_filename,"rb") as gcode_file:
IOError: [Errno 21] Is a directory: u'/home/pi/.octoprint/uploads/Prusa_Mini/Parts'
2020-04-27 08:11:37,188 - tornado.access - ERROR - 500 POST /api/plugin/prusaslicerthumbnails (::ffff:192.168.225.106) 181.30ms

[jneilliii]

Do you happen to have empty folders? That's the only reason I can think of that would cause this, because I did test sub folders.

[blackbird042]

Folder mentioned in log is or is not empty, depends how you look at it. It has no gcode file, but there are two subfolders in it, both with gcode files.

[jneilliii]

Ok, thanks. So probably a recursion issue for deeper folders.

/home/pi/.octoprint/uploads/Prusa_Mini/Parts

The Parts folder has subfolders, but no files? I just want to make sure I setup my test environment the same to debug/ develop fix.

[blackbird042]

Yes, Parts folder has subfolders, but no files.

[jneilliii]

Thanks, I've been able to reproduce. I wasn't really happy with the recursion anyway, so I'll see what I can do to fix this.

[jneilliii]

So this appears to be a bug with the core OctoPrint internal module for file listings. I have opened a ticket here about this. I have also tweaked the code to get past the error, but those deeper files will still not get picked up. You can reinstall using the same URL above.

In order for those deeper files to get scanned you'll need to upload a blank gcode file into those folders that only have sub-folders for now until that issue gets resolved in core..

[jneilliii]

Actually, I take that back. The fix for getting around the error still doesn't get those deeper folder/files so looks like a larger recursion issue upstream in the module.

[blackbird042]

I've reinstalled. As you have written, now all files in first level folders have their images. Anything further down is without images.

[mvasilakis]

It's the damdest thing. No matter how many times I restarted the Pi or PS yesterday I couldn't get thumbnails to render on the one pi. Today they started working again on 0.0.6 on the Pi that refused to work yesterday. I don't have any empty folders on the Pi but I am using a Toshiba Flash Air with the DCIM directory on the Pi that had issues. Not sure it's related because nothing changed from last night to this morning.

Sorry for the speed bump post. If I think of anything that could have caused the issue I'll post back.

[jneilliii]

I've made some styling changes to the scanning part in the same version above. Added a warning if deeper sub-folders are detected so you'll at least get a message as to why it's not working.

[jneilliii]

Releasing a new version 0.1.0 that fixes the scanning recursion issue, you should be able to get all your thumbnails now @blackbird042 once you've upgraded.

[blackbird042]

Great! Just tried it. Working as it should! THX!

[hakan42]

Using 0.1.1, I just re-ran the scanning after renaming one of my gcode subfolders.

Interestingly enough, rescanning did not find any images at all. Reuploading tha same gcodes did properly extract the embedded thumbnails.

I have a print running just now but could try a debugging scan in a few hours. Do you have any suggestion what I should look for in the log files?

[hakan42]

Another note, in the list of "no_thumbnails" in the UI, my files with embedded thumbnails are not shown. It's just that no png is being extracted and put into the thumbnails directory.

[jneilliii]

Thre problem here is a folder rename. Not sure I've accounted for that in code, not even sure how that is handled by octoprint on the back end. My assumption is the images are deleted from the plugin's data folder, and the scan isn't working because it's just checking metadata for the thumbnail property. I'll have to look into this one.