I saw in the release notes that the unnecessary reprocessing of folder thumbnails was fixed. This has been on my list for a long time. I don't think I ever reported it before, because it was occurring only in my massive "family photos" album. I've never had the time to start stripping it down so that I could provide a reasonably manageable, reproducible case. It was also fairly harmless, since it just meant that a handful of files were being recreated and uploaded again.

I had tried switching folder thumbnails, making the album, and then switching back, which sometimes would cure the problem for a folder, but it didn't work every time.

Alas, it's still there in jAlbum 33.1.

Perhaps if I knew what the source of the problem was/is, I might have more luck in helping to track it down.

Yes, but it's fiendishly difficult to track down. Take a look at the screenshot from Windows Explorer, sorted by date. I haven't made any changes in those older "decade" or "year" folders in ages. And there are subfolders under some of those, so tracking down the ones that have been re-gened is messy.

Thanks. Unfortunately I can't still reproduce that problem.

It might help if you could explain, in simple terms, what the core is looking at to determine whether it needs to reprocess a folder thumbnail or not.

While it's not the problem I've been seeing, I have identified one condition that leads to the unnecessary regeneration of a folder thumbnail, and I think it's easily reproducible.

Create a new project, and create a single folder. Add a few images to the folder and make the album. Look at the time stamp on the output folder thumbnail. Now exclude one of the images in that folder - not the one being used for the folder thumbnail, but one of the others. Make the album, and I believe you will see that a new folder thumbnail has been generated.

I can't shake the feeling that this is somehow related to the "new folder thumbnail every time" error that I've been seeing, though in my case it's creating a new folder thumbnail for just a few old folders in the project, not for all of them, and no changes have been made to the older folders (and there's no new index.html for each of them, either).

I'm going to mark this "answered," as I have figured out how to cure the problem. And the cure appears to be permanent.

There were two situations that gave rise to this "no change to the folder, but a new folder thumbnail" phenomenon.

The first involved fairly recent images, from the digital era. In one "problem" folder, I had 20 images, but in looking at albumfiles.txt, only the first 17 of them had camera dates. These were all taken with the same camera, on the same trip, just a few years ago. The images all had perfectly valid camera dates.

Why was jAlbum not picking these up? I have no idea. But I edited all the camera dates out of albumfiles.txt, and then reopened the project. I opened the folder for editing, and just looked through the images in edit mode, to give the core a chance to rewrite the camera dates to albumfiles.txt. Upon making the album, I got a new folder thumbnail, as expected. But that was the last time. Subsequent remakes were fine. And albumfiles.txt was now showing all the camera dates.

The second situation involved images from the pre-digital era. These, of course, really shouldn't have any metadata. These were scans of prints and slides. But various image processing apps had written all manner of spurious metadata to the files, including some completely fictitious "camera dates."

The solution was to edit the handful of "camera dates" out of albumfiles.txt, and then to put the source images through a little utility program I have that strips out all metadata - EXIF, IPTC, xmp. It leaves only basic file information, and the rudimentary "yes, this is a JPG" kind of information. Same result as in the first situation - one more new folder thumbnail, but then no further recreations.

My guess is that somewhere along the line, some stray non-printing characters found their way into albumfiles.txt. Each album build caused the core to try to "fix" the file, but unsuccessfully. So, the file was "new" every time, and a new folder thumbnail got generated every time.

If David wishes to pursue this further, I do have one "preserved" project that shows the bug. But it's tough to experiment with, because if you do anything that prompts the core to write out the camera dates again, the problem goes away.

Check your email.

Thanks for assisting with testing Jeff. I'm now pushing out this fix to owners of v33.3. Those who download jAlbum now will get v33.3.1.