XYplorer Beta Club

Finally something to deal with those cache! Thank you!

I can finally use both XnViewMP (primary viewer for large folders) and XYplorer without having an annoying time of cleaning up XYplorer cache manually all the time!

Hi Enternal, thanks. Just curious why you are using XN viewer? Any advantages? Are you using it for image viewing, thumbnails or both? Have you tried ImageEye or JpegView for very fast and high quality image viewing?

Hi Stef123, I see you also mentioned XNView. Are you also using it for thumbnails or image viewing?

Stef123 wrote: what I am hoping for is a feature that scans tree branches by itself, without manual folder browsing. This is not related to maintenance and cache cleaning, but rather to data I won't use again. For these tasks I set up a seperate thumbs-directory that I delete afterwards.

So I want to make sure I understand you correctly. Are you saying you'd like to be able to go through a folder or even a drive and all it's sub-directories and delete all the thumbnail cache associated with that folder and all it's subs? Would you select the select the folder from which the scans starts?

klownboy wrote:Hi Enternal, thanks. Just curious why you are using XN viewer? Any advantages? Are you using it for image viewing, thumbnails or both? Have you tried ImageEye or JpegView for very fast and high quality image viewing?

Hi Stef123, I see you also mentioned XNView. Are you also using it for thumbnails or image viewing?

Stef123 wrote: what I am hoping for is a feature that scans tree branches by itself, without manual folder browsing. This is not related to maintenance and cache cleaning, but rather to data I won't use again. For these tasks I set up a seperate thumbs-directory that I delete afterwards.

So I want to make sure I understand you correctly. Are you saying you'd like to be able to go through a folder or even a drive and all it's sub-directories and delete all the thumbnail cache associated with that folder and all it's subs? Would you select the select the folder from which the scans starts?

It may sound funny but I... use them all. So XNViewerMP is my primary viewer for folders with pictures. I really like it because of how fast it process many images and how well it displays them then in thumbnail view. So I always use it when I need to view many many images and as good as possible. The way I use XYplorer is a bit more complicated. I have paper folders where my "favorite" pictures are located in. So when using XYplorer, this is the primary use of it and also for folders with less amount of files. While browsing pictures in XYplorer, if there's an image I want to have a bigger look at, I have JpegView as my primary image viewer that's associated through PFA. I actually also have several backup image viewers set up in PFA and that is FastStone Viewer (since it has very easy to use crop and resize functions) and HoneyView(mainly there because it has the capability to browse images within archives). There's also ImageEye but it's not setup in PFA at all and simply located in the same folder as my other image viewers. I do use XYplorer's built in preview too but it's not used as a large picture viewer but more of a "mini" viewer that's usually set to be twice or three times the size of the my current thumbnail size.

Actually, I also have FastStone Viewer as an alternative to XnViewMP and it was my main one for a very long time and that's because it has one of the best full screen capabilities and it still is. You can view pictures in full screen and by simply moving your mouse to the top of the screen, you also get a very nice scroll horizontal scroll window with large thumbnails and quickly select pictures to show in full screen is just plainly excellent. Nothing can come close to this so far from any apps I have tried. Unfortunately I have pictures that have diacritics or use Unicode and that's where FastStone has issues. It's not fully Unicode so certain things show up fine but other things do not. Here are some pictures of it. You hover your mouse at the top and you get that thumbnail view to quickly select the next picture for full screen viewing. You hover to the left and you get an edit pane. Hover to the right and you get an info pane. Hmm... perhaps Don should make something like this in full screen view? Yeah it's over complicating things but I it that way for my usage.

EDIT: Interestingly enough, after talking about FastStone Viewer's full screen feature, apparently XnViewMP had it implemented. It wasn't there in the original XnView. Guess someone liked it!

Enternal wrote:I have JpegView as my primary image viewer that's associated through PFA.

Same here. No faster portable viewer I know of. The only thing I have not been able to accomplish is Copy/Move to folder... - although it should be possible with JpegView's batch-scripting. This gap is filled by HoneyView (more "portable" and lightweight than FastStone and XnView).

FastPictureViewer - while it was still free and lightweight - had this great feature to overlay the letter "C" onto all pics you had already copied. But the old version does not run on 64 anymore.

klownboy wrote:Are you saying you'd like to be able to go through a folder or even a drive and all it's sub-directories and delete all the thumbnail cache associated with that folder and all it's subs?

Thanks for asking. Yes, the idea is to select a whole tree branch including all subs. Right now I achieve this by right-clicking "Check All" in your dialogs, then de-selecting the (smaller) portion of other branches I want to keep. This refers to both, Cleaning + Refresh functions.

klownboy wrote:Hi Stef123, I see you also mentioned XNView. Are you also using it for thumbnails or image viewing?

Yes. Its only purpose is to avoid the sluggish thumbs display of XY when I first browse a folder structure on a foreign machine or drive.
http://www.xyplorer.com/xyfc/viewtopic.php?f=7&t=3981 seems to take care of it - now that I deleted the #302; line. Not sure if you would like to integrate this into your script. It's not really maintenance, but "comfort" to have XY scan an entire branch to get it ready for instantaneous user-browsing.

Thanks again for your script, Ken. It really fills a gap within XY.
I will be offline and cannot report back before Tuesday.

Thanks Ste123 and Enternal for the information though I shouldn't have asked on this thread

Stef123, I know you're off line for awhile, but I'm still a little confused on one issue especially after reading the previous post again. You would like to start the script from a pre-selected folder, (i.e., the current folder when you click on the menu) and be able to either refresh the thumbs associated with that folder and all it's subs or as another option, delete the caches for the folder and all it's subs?

By the way, I think I could also have this script perform all these cleanup and deletion operations in a separate instance of XY such that when its going to the folders to rebuild cache, it will would do it in another window. It might be nice to be able to hide the window such that's it's all done in the background (unseen), but I don't think it would be possible with all the goto's to refresh (#501 requires us to be in the current folder). I have a script setup now to view the thumbs of all my primary photo folders by running a separate instance of XY. A separate instance of XY is started, the folder is displayed in thumbnail view with no XY bars and no titlebar (with the help of AHK) - a nice clean look and quite fast. I close the new instance quickly with the press of the "`" key (I think it's called the Grave accent key).

Version 1.02 - updated script. I think it's a more complete thumbnail maintenance script now.
1. Script was a little slow to display the menu since I had it doing a significant amount of work in the thumbnail cache database prior to screen display. Instead of doing this cache info gathering work in "_Initialize", I changed the script to do it in a sub after menu display.
2. I made 3 new options that are based on your current folder location as opposed to the thumbnail database files though it will update the DB files as appropriate.
   a. "Thumbnail Cache Clean-up [current folder & subs]" - This will essentially delete all the thumbnail cache from the current folder and all its subs and update the DB by comparing all the folders with those in the thumbnail cache.
   b. "Build Thumbnails Cache [current folder & subs]" - This menu item will build a new data base of thumbs for the current folder and all its subs. It makes no difference if there were some folders which had pre-existing cache or not. It will (actually in this case it's XYplorer itself is doing the work) either write new thumbnail cache or write over ones (i.e., "dat2" and "dbit" files ) that already existed in the XY thumbnail folder.
   c. "Refresh Existing Thumbnails Cache [current folder & subs]" - The last new menu item will do the same thing as the option above, build a thumbnail cache for the current folder and all its subs, but in this case it will only re-build the cache for the folders that already have thumbnail cache. So it's not making any new ones for any of those folders that didn't have a cache, only rebuilding the cache for the folders that had one. I think this option is very handy to keep the database trim. Remember thumbs will will stay in the DB when you move, delete and rename images so if you've done a lot of that, it may be much larger than it needs to be.Note if you select a folder which has many sub directories below it, it will take some time obviously to generate the new cache for each of those folders. Let it do it's work. You will get a message in the status bar that it's has been completed. Certainly don't be in the root of C:\.
Thanks Stef123 for making me realize that an option based on the current folder would be a good idea.

Next: I may work on performing the rebuilding of thumbnail cache in another instance of XY.
Please let me know if you have any issues. Thanks,
Ken

I just noticed it pre-selects non-existant folders during cleanup — a nice surprise!

A feature request: remember original location of tab, and go back there after subfolder-hopping operations are finished.
I placed a `$origpath = <curpath>;` after the $path declarations in :build, and a `goto $origpath;` before the status line (more or less same for :refresh and :autorefresh)

Keep up the great work!

Thanks Sammay for checking it out and the comments.

SammaySarkar wrote:I just noticed it pre-selects non-existant folders during cleanup — a nice surprise!

I'm not sure I follow you on this comment..."pre-selects non-existent folders". Is there a problem with one of the options? The "Build" will refresh the current folder an all its subs whether they had thumbs or not. The other option for Refresh only rebuilds the folder and subs which had "existing" thumbs already. Which as I mentioned, in most cases is the best option to clean up or rebuild "existing" thumbnails since it matches each and every folder with every "dat2 file" in that nested foreach loop. Actually the new cleanup option (deleting cache) does that as well.

I was thinking of doing a return to the original folder, but never did. I'll take care of that on the next update. I may look at performing at least one of the options in another instance of XY to see how it works out. I'd love to be able to do the rebuilding completely hidden to the user, but I don't think it would be possible since you have to use goto to accomplish the refreshing in the current folder. It will be fun to text anyway.

Thanks again,
Ken

klownboy wrote:I'm not sure I follow you on this comment..."pre-selects non-existent folders".

I was talking about the cleanup inputselect.

Oh OK, I understand, you were referring to the "original" cleanup options using the thumbnail database. Yes, that can be handy, doing a quick and dirty check for folders that no longer exist. That option should probably be first taken first when in the mood to "clean-up" your thumbnails. Thanks Sammay.

Me again. This doesn't really apply that setting on the fly, so if that option was disabled, all later #501's still (re-)generate only the visible files' thumbs. So I suggest selecting all files in folders and triggering #506 instead of #501 (only if CreatAllAtOnce == 0)

You can check it out. Disable "Create All Thumbnails at Once", save settings. Delete the thumbnail cache of a folder with more than one screen of files, then use Thumbanil Maintenance to build that folder's cache. Then scroll down.

SammaySarkar wrote:This doesn't really apply that setting on the fly...

Tested you are absolutely correct. I probably should use #506 when the setting is off (especially since I requested that command ID from Don ) and I certainly don't want to have to save settings or save settings and restart to have it take affect.

It's funny though, I've been working on another version which will accomplish the refreshing or rebuilding in a second instance of XY, hidden from the user (other than a message saying it's complete). This way so you could continue using XY while the script is working. It's working fine, but I need more testing. Anyway I tested this version, as you laid out above in a folder with a deleted thumbnail DB with that setting turned off and saved, I even restarted XY to ensure it was off. It looks like the "/new" instance of XY run via "cmd /c" is obeying the setting change even though as I said, the setting was disable before I run the script. Yet, the setting is still "off" or unchecked when I return to the original instance of XY and that makes sense.
Thanks again Sammay,
Ken

You made my day, klownboy - thank you so much. This is better than expected, in fact, better than XnView's "add folder to cache" because your script doesn't require me to browse for a folder, it builds the cache on the current selection, very convenient.

Removing branches and twigs from cache works just as flawless and smooth. GREAT. This gives full control instead of the rather crude delete all, then start from scratch.

What totally eluded me on the first go-around: the usefulness of live filtering the cleanup dialog. Inspired by your header hint "Base selection on..." I tried a few things and it just killed me - too good to miss out on this feature. Together with the preselected tick marks for the current branch (thanks for integrating this wish) it offers superb flexibility in targeting subsets.

Nothing else I could think of, really. As an icing to the cake, I may duplicate the Build Cache parts with additional #1, #2 or #3 size entries (replacing #308 with #306 and 307 in the right places). Unless you advise against it? In case of any cross calls within the script that could get affected in a bad way?

I switched icons between the maintenance header (gave it the broom) and "Build Cache" (it got thumbsview). And retired XnView.

Many thanks for providing this tool. While typing along, too many applause smilies began cluttering up this posting, so I took the broom and swept them to end.

Stef

Thanks for the comments Stef123. I finally realized how nice your idea was - to work off the "current" folder. I will be following up, maybe later today, to incorporate Sammay's comments above concerning "Create all thumbnails at once" (for those who don't have that options checked) and returning the user to the current folder at the end of the script. Yes, feel free to experiment and change the thumbnail sizes or add new menu items for different thumbnail sizes. Just make sure you use the first option to cleanup the thumb cache in the sizes you no longer want. You should see double entries for that folder with the two or three different sizes.

And yes, I noticed I had the broom in the wrong menu option...oops.

I'm actually very close to issuing 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. I will probably have the message one you have to click through instead of a the status bar since you could be doing work in the first instance of XY and miss the status bar type message especially since it's changing all the time.
Thanks again,
Ken