Script: Thumbnail Maintenance

[Stef123]

... another change which will do all the refreshing or rebuilding in another instance of XY completely hidden from the user other than a message which will come up and tell the user it's done.

Intriguing idea - not having to take a break and wait for the script to run its course.
Meanwhile, your script is working overtime. Been taking it for heavy duty spins all day - it's absolutely marvellous. I am cleaning out huges caches that have piled up, and 2) generating caches during phone calls and breaks. Expecially shots from digital cameras (hi-res mega pixel stuff) benefit greatly from it. The larger the photo, the longer it takes XY to create thumbs, it seems.

Right now it is running without supervision on another machine where I dumped the content of a friend's camera, thousands of pics, all unsorted from various travels, stored in subfolders per day. This would take a looooong time to browse in regular XY, waiting and drumming your fingers while waiting for the subfolders to deliver their thumbs.

Thank you, Ken, I really appreciate this.

[bdeshi]

Since it's going to use a new instance, taking a little longer to fonish* finish doesn't matter much. So can you add a tweak that creates thumbs for all views (3xthumbs, 2xtiles) in one go?

*blame touch keuboard

[Stef123]

...can you add a tweak that creates thumbs for all views (3xthumbs, 2xtiles) in one go?

Great idea. At first it may appear counter-productive to the original purpose of cleaning and purging which brought this project under way. But for the sake of convenience, maintenance also implies efficiency, keeping the db in good shape, for fast browsing and instant access.

So yes, I am all for it. One-click-caching, the whole enchilada, for situations where time and space don't matter. Then sit down, relaxed and knowing to get served whatever size you may care for.

[klownboy]

Issuing version 1.03. This version is an update to incorporate Sammay's comments and some additional tweaks. One to get back to the original drive when you finish cache maintenance and also use select all and refresh all selected thumbs (#506) in lieu of command ID #501 if the user does not have "Create all thumbs at once" checked in Configuration. This will not be necessary in the next version since the new instance of XY will obey the changed setting to "Cache all thumbs at once". I also added another safety belt if you're in the root of any drive. Based on personnel experience you don't want to build a cache for every folder under the root...no, no. no. I let it go and do it work (hey I'm just testing) and 698 folders were cached...oops. I had a lot of deleting to do. So this change will warn you.

I wanted to update the last version1.02 with the above changes and some additional tweaking, but the next version for accomplishing cache maintenance in another instance of XY is complete. I just want to give it some more testing after I babysit my grand kids.

I'm not sure I like the idea of building the cache for folders in every size possible. Just because work happens in the background doesn't make it desirable at least to me. It seems to go against the grain of what we're trying to accomplish and would also promote bloat. And, it's also something every user can do right now if when they want. The script would only automate it, Of course you could say that about all of this. I'd be more tempted to ask the user what size thumbs they desire for a particular folder, change the view and build the new thumbs. Another possibility, I could determine what the thumbnail size/type is after going to the folder and rebuild based on that information requiring no user intervention. I'll think about it some more, though I'll issue the next version (maintenance in a second instance) first.
Thanks and again please let me know if you have any issues,
Ken

[klownboy]

Darn I just confirmed what I knew before and forgot...getting old. Refreshing all selected thumbs in a script or manually using "Select all" (#250) and then Command ID #506, Refresh Selected thumbnails does not perform a rebuild of the thumbs as does #501. The old thumbs will still be in the data based when you move out images (you can still see the old file names in the "dat2" file). You can test yourself, in a folder of thumbs use #501 to refresh/rebuild all thumbs and check the size of the associated "dat2" and "dbit" file, write it down. Then go back to the same folder remove some images (i.e., move them elsewhere temporarily) and then select all (#250) and then refresh selected (#506) and go back to the thumbs folder <xythumbs> and recheck the size. It will be bigger not smaller. Then return to the image folder in the same thumbnail view and run #501 (do not select anything). Now when you go back and check the database files you'll see the database will be trimmed down to reflect the actual state.

So until I issue the next version, which will obey the "Create all thumbs at once" setting in the new second instance of XYplorer, I'd make sure you have the setting checked. The folder thumbs using Select all (#250) and then Refresh thumbs (#506) is truly only a "refresh" of exisitng thumbs. It does not "rebuild" the data base cleaning out renamed, moved, or deleted thumbs like #501 - Refresh thumbnails (it could be called rebuild thumbnails).
Thanks,
Ken

[Stef123]

In previous versions I could simply sit in a folder and the cache would be built on this location and all subfolders. Now with 1.03, however, I have to step up and actually select a subfolder. I nothing is selected, it will create the cache on the whole drive.

… get back to the original drive when you finish cache maintenance
… safety belt if you're in the root of any drive

The first one seems to work nicely, but I don't get the warning on the root. I do like the idea, though. Canceling out is messy and leaves traces to track down and clean up again. Getting this warning would make a nice feature.

I just want to give it some more testing after I babysit my grand kids.

Combining the two tasks may lead to unprecedented levels of beta-testing.

… ask the user what size thumbs they desire for a particular folder
… determine what the thumbnail size/type is after going to the folder and rebuild based on that information requiring no user intervention.

Thanks for sticking with it and improving this thing even further.
Stef

[klownboy]

Sorry Stef123, I didn't think I had changed anything regarding the folder selection in either the tree or list only the warning if it's the root. I'll check it out. To help me troubleshoot and narrow it down, are you using the "Build" option in this case? When you said, I could just sit there and not select anything, I'm not sure what you mean. Even in previous versions, I intended that you have pre-selected a folder from either the "tree" or "list" selected. It may have used the <curpath> if focus was on something other than the "list".

I just ran more tests with version 1.03 and I'm getting the "root" folder warning if I select the any root folder in either the list or tree and if I don't have a folder selected (e.g., a file), I get the message that I don't have a folder selected. Thanks.

[Stef123]

Sorry for causing confusion. I double-checked the old version to make sure I am not mistaken.

1) My list shows the details view of D:\pictures\archive which contains a few pics and tons of subfolders. Nothing is selected. This is what happens when I run "Build Thumbnails Cache [current folder & subs]":
a) Old version: creates thumbs for D:\pictures\archive and all its subs
b) 1.03: creates thumbs for D:\ and all subs (!!!)

2) I trigger the same command from the same view, but this time with a selected (not entered, just highlighted) subfolder D:\pictures\archive\vacations:
a) Old version: creates thumbs for D:\pictures\archive\vacations and all its subs. Interesting twist: Should \vacations\ contain pics only and no subs, the script will display the root D:\ after it has run its course.
b) 1.03: creates thumbs for D:\pictures\archive\vacations and all its subs.

3) Same command triggered from D:\ - nothing selected
a) Old version: creates thumbs for D:\
b) 1.03: creates thumbs for D:\ (without root warning)

What it boils down to, imo, is the handling of building caches. Does it expect me to always select a folder or drive beforehand? I have no preference, but it should be consistent.

For the sake of simplicity, it were probably easier if NO selection is required. Multiple selections are not respected anyway (no problem but it might cause confusion when you inadvertently have more than one folder selected and the cache being built is based on a folder you had scrolled out of view). Ignoring selections wouldn't be a problem, you just know the cache will be based on your current list view - no ambiguities, no inconsistencies. It wouldn't matter whether the current location contains subfolders or not. This is where the cache gets build. Period. Should you happen to sit in D: a root warning pops up. Other than that, no further checks are necessary.

Just some personal thoughts, of course, I might have overlooked important issues. Thanks for listening.
Stef

[klownboy]

Hi Stef123, interesting results. I'll see if I can duplicate. One point I do know for a fact is that in some cases, the building of thumbs in a folder with only sub folders will not results in a thumbnail database for that folder (dat2 and dbit files). That's not my script, but XY. When you put one picture in that folder, you'll then see that thumbnail DB files were built. It's not consistent though. It may be dependent on the contents of the sub-folders (e.g., if there's an image in the sub-folders(s) - like a jpg file. It didn't seem to matter that there were icons files in the subs).

It was my intension though, that a folder be either selected (with an deliberate click) in the list (which will use <curitem>) or in the tree (which the script will use <curpath>). The next version (1.04) which I will post today uses a bit simpler and hopefully more accurate method to determine the current folder. If there is no folder selected in the list pane, <curitem> will be "" and then the script will use <curpath> so it's not relying on get focusedcontrol of "L" or "T". Unlike the previous control, if you click into the tree (e.g., the white space) or AddressBar after having selected a folder in the list, the <curitem> will still be valid and be used. I've been using/testing/tweaking it now for a couple days so I probably won't spend too much time solving issues on version 1.03. Version 1.04 will also use a new instance of XY to do it refreshing /rebuilding.
Thanks for all the input.
Ken

[klownboy]

Another update [ThumbnailMaintenance_v1.04] This one will perform refreshing or building of thumbnail cache in a 2nd instance of XYplorer. I've also added another option for a refresh or rebuild of the current folder only [no subs]. This new option will also tell you the size of the thumbnail database initially and after rebuild in the completion message. If there was no thumb database for the folder, it will tell you, and also tell you if refresh doesn't result in a thumbnail database since there were no images in the folder. Stef123 hopefully the changes I discussed in the previous post resolve any issues you were having.
Thanks and again please let me know if you have issues.
Ken

ThumbnailMaintenance_v1.04.zip

(317.43 KiB) Downloaded 154 times

[lian00]

Sorry to interfere in your discussion. It seems there is no other solution to refresh ONE thumbnail except your script ?

[klownboy]

To refresh one thumbnail simply select the image and then right click on the "Views" Customized Toolbar button and select Refresh selected Thumbnails (better). It will refresh or rebuild that one thumbnail selected (or all select thumbnails). You can also access that that option through the Main Menu | View | Caches. If you select all (using Ctrl -A) and use that option, it will not rebuild the thumbnail database for that folder however. You must use Command ID #501 or "Refresh thumbnails" for that purpose.

[lian00]

To refresh one thumbnail simply select the image and then right click on the "Views" Customized Toolbar button and select Refresh selected Thumbnails (better). It will refresh or rebuild that one thumbnail selected (or all select thumbnails). You can also access that that option through the Main Menu | View | Caches. If you select all (using Ctrl -A) and use that option, it will not rebuild the thumbnail database for that folder however. You must use Command ID #501 or "Refresh thumbnails" for that purpose.

Thank you so much. I'm not sure I would have find this alone...

[Stef123]

Stef123 hopefully the changes I discussed in the previous post resolve any issues you were having.

Yes, thank you, this update does indeed take care of my issues reported above.

Two new problems have been introduced, however:
1) "Build cache for current and subs" shows this message in the status bar:

report done in # ms

This message comes up way too soon, and stays there. All the time the script seems still busy working, but I can only guess if it has finished or not.

2) Not sure whether it is still at work, I decide to ESC out of it. This brings up an XY dialog "Stepping through a script" from which I copied this line:

Code: Select all

run "cmd /c <xy> ""$path"" /new /win=tray /script=""::if(get('View') < 4) {#308;};#501;wait 20;if(get('instance') == '2'){exit n;}""", , 2, 0;

I click "Cancel Script". When I try to call up the script again, I get this error message:
A user-defined command (#1435) is not allowed to call itself
The ID refers to category "Load Script File" where I simply call the script via
..\Scripts\ThumbnailMaintenance.xys

I suspect both issues may be related to using a second instance of XY.
Would you mind offering an alternative script that does NOT use a separate instance of XY, but otherwise offers the same features?
Thank you
Stef

[klownboy]

Hey Stef123, the report message in the status bar is not unusual, it's expected. I see it too. It's the script running SC "folderreport" which automatically gives that message in the status bar and it will stay there for quite some time since nothing else is providing a new message. The script has barely started its work when that message comes out. It hasn't even opened the 2nd instance of XY yet. You'll see an XY icon in the tray when the 2nd instance starts. Keep in mind that this 2nd instance of XY running will not run the script any faster. If you have a bunch of folders with many images in them under the selected folder, it's going to take XY some significant time to rebuild the thumbnail cache of every single one of those folders. This script can't make XY's rebuild go any faster and you know it can be slow...it only automates the rebuilds. My advise is first to try it out on "one" folder or a folder with only a one or two sub folders below it. When the script is all done and the cache(s) rebuilt, a message will come up requiring you to hit OK. Let it run until you get that message. You can do some things in the original XY while the script is working.

EDIT: I'll provide a status message that will tell you, "Refreshing thumbnail cache for $sel_folder...please wait". Where $sel_folder is the folder for which it's currently building a cache so it will change the message for each foreach loop/folder it's working on. This way you'll know what's going on status wise ,and at the same time, it will override the last "report" message which stays on the screen quite awhile.

That line you quoted is the script line which runs the second instance of XY and rebuilds the cache folder by folder. It's run for each and every folder and it's subs. So it doesn't surprise me what you got when you tried to escape.

No, I don't mind providing an update to version 1.03 which doesn't use a 2nd instance, but try what I mentioned above in the meantime and not on a folder with a ton of subs at least not to test...and then go get a coffee after you start the script...and when you come back to the computer the message box should be on the screen.
Thanks,
Ken