I have been using tiger skin for a very long time. I know the skin creates the shareimage.jpg as an internal file for social media, but my question is why is this now showing in the generated index.html pages. I have even tried adding it to the exclude regex, but no look. I'm not sure when this started happening, I dont care that its generated, but it should not be visible in the index pages.

We're going to need a link to an album that illustrates this problem, especially since no one else has reported it.

I'm seeing a lot of puzzling "messing about" going on in there, so it's difficult to determine where, exactly, this problem is originating. But as a quick sanity check, open the album project, and navigate to the Oldest Bars > PA folder. Switch to the File name view (upper right). Are you seeing a thumbnail for shareimage.jpg? If so, delete it. It would not have put itself there, so it's difficult to imagine how it got there.

But beyond that, I'm also seeing some signs of problems. You seem to be trying to get the project to ignore JPG images, and use only HEIC's. This is misguided. HEIC is a patent-encumbered beast, and processing of HEIC images in jAlbum is very slow. In short, they should just be avoided. Switch your phone to giving you only JPG's. The small reduction in storage space offered by HEIC just isn't worth the resulting headaches, not to mention the utter lack of support for them in most browsers.

You should never have a JPG and an HEIC with the same base name in a project. This is just begging for trouble. So, when I see this in the control files, alarm bells go off:

20240803_143730.heic		1722978929
20240803_143730.jpeg		1722999557

jAlbum will try to produce a JPG slide image and thumbnail for each of those, but those will, of course, just be duplicates of each other. Lots of opportunities for fatal collisions.

Stick to JPG's.

Then do some cleaning up of your settings. Go back to the default Ignore pattern, and join the rest of the 21st Century and use UTF-8 for everything. See screenshot.

Bingo. I hadn't even checked for that, because I haven't seen anyone try it in a few years. But that appears to be what this user has done. From the settings file:

directory=z\:\\htdocs\\mb\\album
outputDirectory=z\:\\htdocs\\mb\\Album

Windows is not case sensitive, so in this case, those directories are identical.

Under some circumstances, the app doesn't warn the user about doing this, and when you do get the warning, it isn't nearly emphatic enough. I agree, since this will always produce bizarre problems, the album build should immediately abort, with a clear dialog box explaining why. It should not be able to proceed.

Untangling things is going to be somewhat challenging, since at this point, inputs and outputs are intermingled. The usual core routine that offers to move the output if you change the output directory won't work, because the core can't tell what's input and what's output.

You're probably going to have to bite the bullet and manually delete all of the output material from the project directory, change the output directory location, and make the album again. It will have to reprocess all the images, and upload everything again, but only once, thankfully.

The cleanup will have to take place outside of jAlbum, to avoid further damage. Decide on a new location for the output - the default is for the output directory to be a subdirectory of the project directory, but it can be elsewhere if that's better for you. Change that under Settings > General > Output directory, save the project, and close jAlbum.

Given the skin you're using, the things that should be deleted from the project directory, out in the operating system:

• res folder at the top level
• slides and thumbs folders at all levels
• all .json files
• all index.html files
• all folderimage.jpg files
• all folderimg.jpg files
• all folderthumb.jpg files
• all shareimage.jpg files
• lifeboat.zip

Then launch jAlbum, open the project, hit Make Album, and go do something else for a while.

If anyone can think of a more clever way to pull this off, I'm all ears. Bear in mind that this project has a very extensive folder structure, so doing something like moving the slides and thumbs would be pretty labor-intensive.