Extracted Thumbnail in Source GCode Path?

[jlong23]

Since the plugin modifies the ".metadata.json" with the paths of the thumbnails, would it be possible to store the extracted thumbs with the same path as of the GCode?

Reason is that if you have a NFS Share of all your GCode with multiple Printers pointing to it, it's now shared and the Thumbs match the Shared ".metadata.json" paths as well.

[jneilliii]

The problem with that approach I think is that the image files would also be included in the file list on the left, which is not ideal. I'd have to double-check that though and won't be able to for a while.

[bolsoncerrado]

OK I guess I spoke too early. Further expanding "issue" #95 I'd like to add that I managed to map or link the thumbnails folder to a unique NAS folder where all my Pi's look at so any .gcode with thumbnails do generate the .png in such folder....or at least at random.

Sometimes I have to reupload the same file once or twice for a specific Pi to properly show/detect the thumbnail.
Sometimes it works at first shot.
BUT
the most puzzling thing is that in a instance (Pi) I haven't uploaded yet any .gcode with thumbnails, if I refresh the file list, SOME files show up with the thumbnail available and some others don't!

I don't get it!!

Can't the meta file just find the thumbnails all the time the same way the file list finds all the files all the time??
Or am I missing something!?

Thanks!

[bolsoncerrado]

So to try and further troubleshoot this....

I just uploaded 2 gcode files in 2 sepparate Pi's, the one in the top left as you can see and a Pi located to its right.

As you can see in the right half of the screenshot, the thumbnails were stored correctly on the NAS folder.

However NONE of the uploaded files show up with the thumbnail icon available, nor no thumbnail is loaded after upload finishes :?

However I'm pretty sure if I reupload the same files again, they will show the thumbs fine :????

[bolsoncerrado]

However I'm pretty sure if I reupload the same files again, they will show the thumbs fine :????

And this just happened! I reuploaded the same files on the same Pis and now the thumbs showed fine.

I sliced and uploaded a totally different gcode on a totally different Pi and same scenario: first, no thumbnail. Reupload+Overwrite=thumbnail

:??????

[jneilliii]

The only thing I can think of in this scenario is a possible caching problem. When you upload once to one pi does the thumbnail show up in that instances' interface? What happens when you press the refresh file list button? Any errors in browser's console log?

[bolsoncerrado]

That's what in trying to explain. First upload, no errors, no thumbnail shows (but thumbnail appears on the Nas drive). Second upload, thumbnail shows fine.

[bolsoncerrado]

Forgot to add, pressing refresh does not solve the problem.

I may add this may be connected with the fact some Pi's don't show the thumbnail logo of files uploaded on other Pi's even if now the folder for the thumbnails is shared...

SO I guess I'm still missing a symlink or something like that somewhere...

Today, for example, after all printers have been idle after finishing night jobs, I went ahead, created a new gcode, uploaded it and thumbnail showed up at the FIRST TRY!

THat's what puzzles me the most! Arbitrariety!!! :(

EDIT: SECOND upload of the day, issue reappears. Have to upload twice in order for the thumbnail to show up. In BOTH cases, .png file is UPDATED on the NAS folder.

EDIT2: THIRD and FOURTH upload worked fine at first try! The difference? .gcode files were 11 and 20Mb against the SECOND upload which was 50Mb -- dunno if we can find a pattern with this?? will keep checking filesize against fail/success rate to see if there's a connection too.

EDIT3: FIFTH upload failed, and file size theory is BS since this was "only" 15Mb... I dunno if the "File exists, overwrite?" dialog helps in any way to force display the thumbnail!?

[bolsoncerrado]

Hey @jneilliii mind helping me understand the chain of events after upload starts on the Pi?

I mean, it's clear somehow the files ARE uploaded and no matter what, the THUMBNAILS are extracted too, even if they don't show up on file refresh list.

Where is the path to the thumbnails stored and why it would work after several uploads? I mean, if symlink finds them anyway after a few reuploads, what else could be failing?

Thanks!

[jneilliii]

the workflow is at such.

1. file added via OctoPrint's UI and plugin starts the work here
2. thumbnail gets extracted here.
3. if extraction was successful and file exists afterwards then the virutal path to the thumbnail is added to .metadata.json here.

At that point the URL for the thumbnail is in the metadata OctoPrint uses to display files.

This is one of the biggest reasons OctoPrint core maintainer (foosel/Gina) doesn't recommend using a shared uploads folder. I think what is happening is all the files are competing to analyze the file, write the metadata, etc. at the same time. You'd be better off using something that syncs the pi's uploads folder like GitFiles, but not the one registered on the repo, use this fork: https://github.com/tideline3d/OctoPrint-GitFiles

[jneilliii]

Commit above adds the option in settings to Extract images into uploads folder. and is part of 1.0.2rc1. You can change the release channel in OctoPrint's Software Update settings to Release Candidate and upgrade when prompted to test it out and see if it resolves the issue or not. I'm not very hopeful based on the above comments that it will work as symlinks are still involved in this scenario.

[jneilliii]

Only issue I've seen so far is if you have Custom Backgrounds plugin installed, then extracted images are displayed in the file list. That will have to be corrected in that plugin though.

[jneilliii]

included in the above release 1.0.2