Slow thumbnails

[admin]

Yes, that looks like a little cosmetic bug. I don't think it has any consequences in XY (apart from the thumbnail maintenance script). Anyway, I will fix it, of course.

[admin]

Has a new version been released?

Yes, download the beta here from the forum.

[klownboy]

Yes, that looks like a little cosmetic bug. I don't think it has any consequences in XY (apart from the thumbnail maintenance script). Anyway, I will fix it, of course.

Yes, I agree in that it certainly worked as expected which is why it surprised me since the "old" folder was still referenced in the "dat2" file. That seems to mean that XY doesn't need the "dat2" file to display the proper thumbs for a particular folder (i.e., it doesn't make use the "dat2" file when visiting or returning to a folder of thumbnails)? Do you strictly use the proper hash "dbits" file with the actual thumbnail data? I ask because I didn't think the associated "dbits" file had the folder info within it though obviously they share the same hash name. Thanks Don.

[kileytoo]

Has a new version been released?

Yes, download the beta here from the forum.

Done, thank you for looking into this.

[admin]

OK, checked the code, and it's like this:

This path data is not used by program, it's only present in the dat2-file for human eyes (because nothing can reverse-engineer the path from the MD5 filename).
Therefore I allowed myself not to update it on a path rename. It's autoamtically updated on the next cache write.

So, I will do nothing here.

[klownboy]

...Therefore I allowed myself not to update it on a path rename. It's automatically updated on the next cache write. So, I will do nothing here.

That could be an issue under some circumstances especially for the script. As you know, it's reading the dat2 files and detects the folder doesn't exist therefore is essentially recommending deletion by having that cache pre-checked whereas in reality it's a valid cache with a new folder name ...yeah that could be a problem. No way to update the folder name without a lot of pain when XY/you recognize the name change?

I notice the only way to reflect the new folder name in the dat2 file is using cid #501, "Refresh thumbnails". The other refreshes including refresh crisp or smooth etc. do nothing as far as the dat2 file. The only thing I could do from the script standpoint is to do as I'm doing now, determine if the folder doesn't exists then trigger a cid #501, but how can I determine what folder do do it on since it's been renamed. Possibly by comparing the 'hash' of the supposedly non-existent folder with the hash in XTthumbs.txt which will have the correct folder. Untill a refresh, this one situation where XYthumbs.txt file will have more accurate information than the actually database cache files, but I hate using that file since it could be totally hosed or deleted and the thumbnail system works just fine. Thanks.

[admin]

Sorry, but not possible.

I could tell you how the hash is generated. Would this help?

EDIT: Oh, I think I found a way to do it. Seems to work...

[klownboy]

Cool Don, I hope it wasn't too much trouble. I could have found some way to compare the hash of the folder which had been identified by the script as no longer existing and then compare it with same hash in XYthumbs.txt and if the folders differed, warn the user that the folder had been renamed. Either that or just tell users to make sure they've refreshed folders after renaming them at least before using the script.

I'm not sure what you mean by how the hash is generated. I know you've stated before what the hash is based on the combo of folder and thumb size (e.g., hash("md5","E:\6\*240x240");). I'm not sure exactly what initiates this, other than the initial build of the cache or a refresh of the cache.

[admin]

I'm not sure what you mean by how the hash is generated. I know you've stated before what the hash is based on the combo of folder and thumb size (e.g., hash("md5","E:\6\*240x240");).

Correct. I was not sure if I had stated that already before.

[klownboy]

I didn't see the last beta (15.10.0013) 'already' when I wrote the previous post, but I did a few renames with it and all is well as far as the dat2 file updates. Thanks and

[kileytoo]

Any chance a free no install v14 may still be available for download?

[admin]

why?

[kileytoo]

Because v14 did not have this issue

[admin]

I would bet it's a difference in configuration... Compare both versions in a fresh instance...

[kileytoo]

I think the two threads got mixed up?