Slow thumbnails

[kileytoo]

Hi, not sure if a bug report or a wish. I am using XYplorerFree 14.60.0200 and I love it, it's so much an improvement over what comes with Windows 7, but the thumbnails are slowing me down so much that sometimes I have no choice but open up Windows Explorer (ugh!) I have two issues. One is that all thumbnails are recreated for no reason when I simply rename a folder. I don't mind waiting a few minutes for thumbnail creation the first time, but it's frustrating having to wait all over again when I know the files have not changed at all, only the folder name, and the new thumbs will be exactly the same as the cached ones (no need to recreate them). The other issue is that while I wait for the thumbnails to be created, I cannot scroll down and simply pick the file I need because the scrolling becomes unstable and unresponsive. If I drag the scroll bar down halfway and try to move the mouse to click on a file, the scroll bar moves automatically down, out of my control, before I can do that. If I try to drag it back up, it goes down again as soon as I drop it, so there's nothing I can do but wait untill all thumbnails are created. (Create All Thumbnails at Once is unchecked.)

[admin]

Please check the latest version. It's been improved.

[kileytoo]

Thanks, I just upgraded.

[kileytoo]

So I have been able to narrow down the source of my issues. I thought it had something to do with PSD files but it also happens with JPEGs, so all graphic files. The issue is that thumbnail creation is slow for large files. Each image can take several seconds, so if a folder has many images it can take a few minutes to create all the thumbnails.

That's fine, every once in a while I can just take a few minutes break and do something else, the problem is that *all* thumbnails are recreated *everytime* I rename the folder, which is really not needed because renaming the folders does not modify the files. So whenever I have to do something quick with my image folders I have no choice but going back to WE, which is annoying because the XYE interface is so much better (for example, creating a new subfolder is quicker and more intuitive in XYE).

[klownboy]

the problem is that *all* thumbnails are recreated *everytime* I rename the folder...

I've noticed this myself on numerous occasions when working on my thumbnail script. I don't think there is any way Don can change the name of the folder "only" in the corresponding "dat2" thumbnail file since the thumbnail "dat2" and dbits" filenames are actually the "hash" of the combination of folder name and thumbnail sizes (e.g., "G:\Photos\Cabo\1920x1080\*240x240"). The filename hash.dat2 and hash.dbits would have to change. So Don would have to recognize a change in a folder name "only" and change the folder name within the dat2 file along with the new hash filename and change the name of the corresponding dbits file possibly without changing its contents. I don't know if that's possible.

[Stef123]

the problem is that *all* thumbnails are recreated *everytime* I rename the folder...

I've noticed this myself on numerous occasions when working on my thumbnail script.

I can attest to that, too. Not just renames, but also different drive letters trigger a complete start-over, even if you store the cache on the same drive. Enable branch view - and thumbs are created from scratch yet again, even though your cache already holds everything it needs, more than once, hard-wired under different drive letters.

The best remedy imo, were to simply speed up the generation of thumbs - considerably. Been wishing for a super-fast mode in low quality, or a 2-step process similar to Google Maps, where you get to see the rough and dirty overview building up almost instantaneous, then - the longer you stick around - better quality gradually takes over.
http://www.xyplorer.com/xyfc/viewtopic. ... 15#p121979

[kileytoo]

Thanks. Come to think of it, the real issue is that XY is not responsive until the last thumb has been recreated. It's difficult to scroll down (the scroll bar has a mind of its own) and you can't double-click on a file name or click on another folder in the directory tree. As a workaround, what about allowing us to stop/skip/cancel thumbnail generation by pressing Esc, or by clicking on a different folder in the tree? I know that there would be incomplete thumbs in that folder, but XY could resume creating the missing ones the next times I go to that folder. This wouldn't be a problem because I could cancel it again , unless I really need the thumbs, in which case I would just sit (or sigh) and wait.

[bdeshi]

the problem is that *all* thumbnails are recreated *everytime* I rename the folder...

[...]So Don would have to recognize a change in a folder name "only" and change the folder name within the dat2 file along with the new hash filename and change the name of the corresponding dbits file possibly without changing its contents. I don't know if that's possible.

Don [probably] has no way to learn how folders are modified outside XY, but he certainly can keep a record of folder-renames inside XY, and update xythumbs.txt + corresponding dat2's accordingly; updating the hashes shouldn't be a issue speedwise (it's only a string's hash).
This shouldn't be too much of a bother; XY is already [unnoticeably, superbly,] doing this exact thing for tagged items.

[kileytoo]

he certainly can keep a record of folder-renames inside XY, and update xythumbs.txt + corresponding dat2's accordingly

That would work fine for me, I have no wish of using WE and I tend to avoid the WE windows that open up in other software apps.

[admin]

the problem is that *all* thumbnails are recreated *everytime* I rename the folder...

I've noticed this myself on numerous occasions when working on my thumbnail script. I don't think there is any way Don can change the name of the folder "only" in the corresponding "dat2" thumbnail file since the thumbnail "dat2" and dbits" filenames are actually the "hash" of the combination of folder name and thumbnail sizes (e.g., "G:\Photos\Cabo\1920x1080\*240x240"). The filename hash.dat2 and hash.dbits would have to change. So Don would have to recognize a change in a folder name "only" and change the folder name within the dat2 file along with the new hash filename and change the name of the corresponding dbits file possibly without changing its contents. I don't know if that's possible.

Yes, indeed. This has worked for years but fundamental changes to thumbs handling around 20140919 left it dysfunctional. I will have a look at it later.

[klownboy]

Yes, indeed. This has worked for years but fundamental changes to thumbs handling around 20140919 left it dysfunctional. I will have a look at it later.

Thanks Don.

...and update xythumbs.txt...

Yes, I forgot about XYthumbs.txt, but that should be the least of Don's problems. That XYthumbs txt file is really only a log that is updated when the thumb folders are accessed. If you delete it, it just starts updating the file with new entries as you access folders with thumbs, but doesn't affect the actual viewing of thumbnails in any way.

[admin]

Fixed completed. Now football.

[Stef123]

- Thanks for fixing it. If only I had known it was broken. Giga-tons of cache data would have been avoided. Teaches me to voice complaints in more detail

[klownboy]

Thanks Don, I'm not sure if the change is working quite right. I placed image files in a folder which originally had no images and then refreshed a couple of times in a thumbnail view. I then rename the folder from "E:\1\" to "E:\6\". There was no thumbnail regeneration or rebuild with the folder name change, so this part of the change worked as it should. I noticed the XYthumbs.txt recognizes the new folder name "E:\6\" (and there is no "E:\1\" - again as it should), but when I look at the hex view of "7e24c013a3c882d98c3e700106e9af41.dat2", I see it still list "E:\1\*240x240" whereas the entry in XYthumbs is E:\6\|240x240|7e24c013a3c882d98c3e700106e9af41 with the same hash? It looks like you have updated the hash file name of the dat2 and dbits files since the new hash for "E:\6\*240x240" is correct "7e24c013a3c882d98c3e700106e9af41". Shouldn't the new hash dat2 file list the new folder of E:\6" and not E:\1 as it does?

I noticed this when using my thumbnail maintenance script in that the script picks up on folders which no longer exists and it pre-checked folder. So folder " E:\1" is pre-checked as no longer existing which is true, but the hash is the same as E:\6 so if I deleted it, the thumbs for the new folder "E:\6" would be deleted.
Thanks,
Ken

[kileytoo]

Has a new version been released?