XYplorer Beta Club

Hi Stef,
Maybe in your case since you are working on some very deep folders which could take quite a while, I should have a message pop up using SC msg instead of SC status on the status bar that way you'd have to click on it. I used "msg" on the background operations, but not typically on foreground ones. My next change I'll use something like you recommended like, "Busy rebuilding folder [so and so]...please wait" (though it should say something similar now) and at the end (of all folders) pop up a message box unless it's an option that has the report pop up. I believe on background ops that's what I do. Use status to say it's working on folder bla bla bla and pop up at the end since you'd never know in background operations. If someone finds the message popping up to be an irritation, they can always change "msg" to "status". Thanks for the input.
Ken

Thank you Ken,
for being open to my suggestion. No rush, whenever you find time.

Ken,

I'm forever changing the names of folders and/or moving the folders, so I needed a way to clean up the thumbnail database files.

I am a bash shell coder, so I installed the Linux emulator CygWin on my Win7 system. I wrote a shell script to clean up the thumbnail database by (1) removing obsolete folder entries (and deleting associated .dat2/.dbits files) from XYThumbs.txt file and (2) deleting .dat2/.dbits files that are not referenced in the XYThumbs.txt file. Since this is all done external to XYplorer, there was no way to refresh or build thumbnails for given folders. Ugh.

I just stumbled across this thread and your script. Well done! Now I have the ability to build thumbnails for a folder and its sub-folders with a couple of clicks - this is an option I feel has been missing from all the goodness of XYplorer.

OK. Now I confess my ignorance and my laziness to dig out the answer on my own. I installed your script in the Scripts sub-folder in Users/Roaming. To run it, I click Scripting, then Load Script File, then double-click your script name. Is there an easier way to start it, such as assigning it to a user toolbar button?

Thank you for all your work and then sharing it with the rest of us!

Cheers,
Gary

single cmd as a CTB's (user toolbar btn) left/Right click script:in fact if the scriptfile is located somewhere inside the scripts folder, you can skip the <xyscripts> and just use the filepath relative to <xyscripts>...

Or - in addition to Sammay's TB button - assign a shortcut in case you find yourself triggering the script as often as I do:
User > Manage Commands...
Pick the category "Load Script File" in the left sidebar of the dialog
Enter ThumbnailMaintenance.xys into the field where it says "Script File"
Click on the command button "Assign Keyboard Shortcut"

Hi m48tx, thanks and I hope the script will come in handy.

Stef123, or anyone for that matter, have you experienced a corrupted thumbnail display after a rebuild/refresh even more so if the refresh is accomplished in a the background? In viewing the thumbs afterwards, many of them are displayed corrupted, but I don't think they really are corrupt. It's just the initial display. When I close and restart XY and display the thumbnails they are all fine. So I don't think it's the script but possibly the change in thumbnail memory management Don accomplished...though that's a total guess. I have no issues at all with my graphics elsewhere or issues with my graphics card. The script does accomplish both thumbnail refreshes and normal refreshes when rebuilding. I'll to test further when I experience it again to see if another refresh solves the problem without having to restart XY. Thanks.

klownboy wrote:Stef123, or anyone for that matter, have you experienced a corrupted thumbnail display after a rebuild/refresh even more so if the refresh is accomplished in a the background?

No, cannot confirm. However, I rarely use the background operations, and what's more, the XY version I run from my stick is an old one, possibly before Don made the change.

SammaySarkar and Stef123:

Thanks for your input! Wow, such quick response. Thanks again.

Ken:

I've had no corruption issues (14.50.0204 on Win7 64bit) but only use script in foreground.

Cheers,
Gary

Been running into problems recently. The script leaves many residues in the thumbs folder, or rather, it's not the script but XY that seems to cause problems.

I went to back to an older XY version and things are fine again.

Hi Stef, when you say residue, are you referring to files other the an the usual "dat2" or "dbit" files? I hope it's not the script's fault. I just took a look since I haven't looked in that folder in quite a while. I didn't notice anything unusual. I mentioned earlier that I "see" some very corrupt thumbnail display (in the original instance of XY) on nearly half of the thumbnails when I look at the thumbs after having rebuilt a huge folder in a background (2nd instance) of XY. When I exit out of XY and again take a look, the thumbs are all just fine. So the thumbnails themselves are fine it's just the display which tell me it's probably a memory issue since the actual thumbs on the drive are OK. Now the fact that it's done in the background (2nd instance) "shouldn't" make any difference. It never has before. It's only started happening after Don made those memory changes for thumbnails (expanded the memory usage).

It was also mentioned elsewhere that when the thumbnail cache is disabled , XY is still leaving residue dat2 files in the thumbnail folder.

Hopefully, he'll take a look at these issues when he returns.

klownboy wrote:It was also mentioned elsewhere that when the thumbnail cache is disabled , XY is still leaving residue dat2 files in the thumbnail folder.

That's probably what happens here, too. I toggle caching On and OFF via CTB. Upon closing XY I don't check up on the cache to see if it kept the the same size as it should. I did so just now, and sure enough, it got bigger even though caching was OFF.

Your script cannot handle such a situation, since these erroneous dat2 and dbits files are not referenced in the txt-file. IMO, it's not a good idea to use the cache folder to store data when caching is off. It should go into a temp folder like everywhere else. If something crashes, you feel more comfortable deleting stuff that resides in a prefixed ~temp-folder.

This is not to say that I'd experience crashes. XY closes down normally.

Stef123 wrote:it's not a good idea to use the cache folder to store data when caching is off. It should go into a temp folder like everywhere else.

So I take it you sometimes turn caching off when working on folders for which you do not want to save the cache. I had mentioned somewhere another thread that discussed remnants when the cache was off) that Don should just delete the entire folder on exit if caching is off, but if users are doing what you describe (i.e., having the cache "off" sometimes and "on" other times) that certainly wouldn't do, would it. You're expecting the thumbnail files generated when the cache is on to still be there after you've used it with the cache off. So yes, based on that usage, Don should consider when the caching is turned off, and if based on how XY is coded, it's still necessary to cache to disk in this case, then the cache should be written else where, as you said, to a temporary folder and simply wiped clean upon exit.

I could probably get rid of remnant dat2 files in the thumbnails folder that are not in the XYthumbs.txt file, but I'd rather see Don correct the issue. In writing the script it was much more important/critical to build the XYthumbs.txt file based on the DAT2 files present than perform cleanups or rebuilds based on the contents of the XYthumbs.txt file. That txt file could theoretically be totally hosed, corrupt, or even non-existent and the thumbnail caching would still work. It appears from what I'm hearing, it's only some of the "dat2" files not the "dbit" files that are left behind when caching is turned off. So, I could do a check of the "base" file names and if there wasn't a corresponding "dbit" file for the same named "dat2" file, the correspoinding dat2 file would be deleted. If Don doesn't change or do something about the left-overs I could have that as a separate option since it would only support those that may turn the cache on and off.

klownboy wrote:...that Don should just delete the entire folder on exit if caching is off, but if users are doing what you describe (i.e., having the cache "off" sometimes and "on" other times) that certainly wouldn't do, would it.

Definitely not a good idea. I even keep different caches for different machines, some of those caches took 12 hours and longer to create (unsupervised thanks to your script).

Granted, I may be an unusally heavy (ab)user of cache management, but if OFF or ON were a one-time global shot, you'd expect it to be an ini-tweak, and not conveniently accessible in the config-dialog. And even then, firing up XY with a different ini might erase a cherished cache and cause a lot of headache, especially for users who have not come across your script yet.

klownboy wrote:I'd rather see Don correct the issue.

I fully agree. Again, your script is not to blame, it has no bearing on this issue. For the time being, I went back to an older XY version and everything is fine again.

Imo, temporary files should be recognizable as what they are, prefixed by ~ or _tmp_ and a program should clean up after itself, no matter where these files are dumped.

Stef, I'll go ahead and add a menu item to clean up any residue left over from runs which had the cache off. If/when Don does something different as far a cleanup when the cache is off I can always remove it later if it's deemed unnecessary. I was planning on a small update to make the notifications more in your face as we discussed a while back anyway.

Thank you Ken,
I really appreciate your offer.

klownboy wrote:I can always remove it later if it's deemed unnecessary.

Sounds good. Unless it gets in the way of other script routines or increases risks of unforeseeable side effects. I don't mind waiting for Don's return to fix these issues. Until then I can easily live with the older XY version that doesn't cause these problems.