2 Thumbnail cache files for same image folder and thumb size

[klownboy]

Hey Don. Happy New Year. How is it possible that I ended up with 2 thumbnail cache file pairs (ini and dbits) for the same identical folder with the same thumbnail size when the cache file name is based on the hash of file name and thumbnail size and zoom settings? I thought it shouldn't matter if some of the images/thumbnails have different mod dates as they do. Nor should it matter that the total number of thumbnails is different or if the image folder was refreshed at a latter date. In this case, the thumbnails would be rebuilt due to a refresh, CID #501 or due to a changed mod dates, but the file name should be the same. Shouldn't it?

The pic below shows the 2 cache ini files where you can see identical folder and file names and thumb size and both are not zoom to fill. I'm just curious as to how it can happen and should it happen at all (i.e., what's causing the different cache file name)? Is it possible that the new cache is due to v26.90.0108 - 2025-02-26 12:04 change viewtopic.php?p=227798#p227798? \

Thanks. Sorry, I know we've been through this before. Thumbnails get rebuilt for a number of reasons, but why in this case would a new cache file name be used (i.e., a different hash)?

thumbnail ini files for same folder.jpg (264.69 KiB) Viewed 305 times

[jupe]

Are both hashes in XYThumbs.txt ?

[klownboy]

Yes jupe both are listed in the XYthumbs.txt file as:

Code: Select all

H:\Pictures\Caribbean Holidays Cruise 2024\|240x240|b3b63c338c34750e6a8f6815e30504e2
H:\Pictures\Caribbean Holidays Cruise 2024\|240x240|cc28206ef594b7394dd3677b1bace670

When I ran text get("thumbs_cache"); in that image folder the result was: D:\Tools\XYplorer\Thumbnails\b3b63c338c34750e6a8f6815e30504e2.dbits - the first on list. Just seems a bit odd in that XY would use a different hash file name for the same folder and thumbnail size both no zoom regardless of the dates and image file mod dates.

[admin]

With each .dbits file there is an accompanying .ini file that you can read in any text editor. Compare the two .ini files, there should be a difference that explains the situation.

[klownboy]

With each .dbits file there is an accompanying .ini file that you can read in any text editor. Compare the two .ini files, there should be a difference that explains the situation.

That's what I did in my first post.

[admin]

Oh yes, very obviously you did.

Interesting case. Did you already compare the Created dates?

[klownboy]

ce670.jpg (27.72 KiB) Viewed 207 times

504e2.jpg (31.87 KiB) Viewed 207 times

As stated earlier when I ran text get( "thumbs_cache"); it's the file ending with 504e2 that is being used. I only picked up on this by running my thumbnail maintenance script since it gives a listing of all thumbnail caches and these both came out adjacent to each other for the same folder. There's another script option which picks up on stray ini or dbits files, but that's not going to detect this problem.

I know changes in the image file mod dates will kick-in a new thumbnail build, but I didn't think the actual file creation or modified date came into play in arriving at thumbnail cache file hash. I was under the impression that the hash value used for the cache file name was based on: image file folder | thumbnail size | zoom value and if I remember correctly branch view also comes into play...but it's been a while.

[admin]

I was under the impression that the hash value used for the cache file name was based on: image file folder | thumbnail size | zoom value and if I remember correctly branch view also comes into play...

Correct.

I can't explain it. Is this the only mysterious pair you got?

[klownboy]

Well I'm starting to believe it has something to do with running this small script below. It simply places a label thumbnail file in the image folder at locations the user selects. I'm not sure how it may be affecting the thumbnail file name - the actual hash. This folder of an Alaska trip has a thumbnail cache file named:
D:\Tools\XYplorer\Thumbnails\00000000000000000000000000000000.dbits How can that happen? Maybe something is a bit wrong with the way the hash is calculated? I even ran a full #501 to refresh that entire folder (590 images) and it still (re)used the same hash file name for the cache. The script does a #506 to refresh the new image file (the label thumb). Performing a refresh on a selected file shouldn't affect the thumbnail cache hash filename.

This Alaska trip folder and the other one above, "H:\Pictures\Caribbean Holidays Cruise 2024\" are the only 2 that seem affected and are the only 2 folders I've used the above script.

Code: Select all

// This script requires ImageMagick thou I'm sure some other graphics programs could do the same
// preselect the file where you want the new text thumbnail header to start (i.e., the resultant thumbnail will be before this file)
// Input caption
   $caption = input("Enter the caption or title of your label file",, "Icy Strait", "s",,400,300);
   $date = <datem mm-dd-yyyy>;
   $dateexif = <dateexif>;
   $orig_selectedfile = <curitem>;
   $filename = $caption . ".jpg";
   $file = <curpath> . "\" . $filename;

   run lax("D:\Graphics\ImageMagick\convert.exe "-background transparent -fill black -gravity center -density 90 -font Arial -pointsize 40 "label:\n $caption"\n -pointsize 24 "label:$date"\n -append "$filename"), , 2,0;

//   Time stamp the selected new file to a couple of minutes before the originally selected file. This will establish proper location of the label file when the folder is sorted by date.
   wait 100;
   selectitems $file;
   timestamp cm, $dateexif, $file, , "-2 n";
   #506;  //refresh selected thumbnail

label thumb.jpg (72.4 KiB) Viewed 185 times

[admin]

00000000000000000000000000000000.dbits ... that's impossible. Sorry, I have no time to dive into your script. I'm sure you can isolate the problem yourself.

[klownboy]

I have a good feeling that it may be due to the label image file generated by Image Magic (e.g., 235x251). The image file dimensions are proportionally based on the text length and point size and not a standard which XY could then generate a thumbnail image properly.

The ini and dbits files are what they are and viewing the thumbs actually works, but that probably happened due to incorrect input like an thumbnail in the folder that's not 240x240 (my thumbnail size #3 setting) and the subsequent refreshing of that thumbnail. So the hash ended up as it is bullsh**.

[admin]

I currently cannot see how "00000000000000000000000000000000" is ever returned by the responsible function, but I don't think it's worth the time looking into this.

[klownboy]

Well it may be worth my time. I say that because I deleted the 2 associated cache files, restarted XYplorer, and built the 590 thumbnails and guess what? The cache file names used again are 00000000000000000000000000000000.dbits and ini. My SSD taking a beating. I placed a number of the same image files in a different empty folder including the one of the label thumbs files and the cache was created properly. Any ideas for a clean rebuild or something else to try?

Edit: I also built thumbs in the same folder but in a smaller size and that created the cache file fine as well.

[admin]

Can you provide a script that doesn't require ImageMagick and reproduces "00000000000000000000000000000000.dbits"?

[klownboy]

Honestly I'm no longer thinking that script had anything to do with it. The script simply made an image file with text in. It refreshed that one selected thumbnail, but did not accomplish the folder rebuildling CID #501. I did rewrite it to make the image file dimemsions a multiple of my thumbnail size (i.e.,2 x (240x240)), but had the same result. I copied many of the same files including the text image files in another temp folder and the thumbs were made with a proper cache file hash. I will take a look later today to see if I can use another image program other than ImageMagick to do the same thing.

One question though, is there something else I can do to fully ensure that XYplorer doesn't revert back to using that bad hash. Again I will deleted the cache files, delete the entry in XYthumbs.txt, close XYplorer, and even reboot. Can you think of anything else I couold do beyond that?