If I add an object that has a related THM file, I get the attached console error, along with the triangle warning at lower right. This happens regardless of the type of object - video, PDF, whatever. Including them with videos these days is fairly uncommon, but for PDF's, it's an everyday thing.
And when I make the album, I get the same error, multiple times, along with some odd delays in the album build, like it's struggling to deal with the THM files - very noticeable.
Ultimately, it doesn't do any harm - the representing image is handled correctly - but it ain't happy.
This is with 24rc2.
Try the attached pair of files in any skin that can handle PDF's - Tiger will do, for example.
I should point out that this is just the latest in a string of errors and user-unfriendly things about the THM mechanism.
There are UI problems when trying to use the THM as a thumbnail image for the folder. It won't get selected automatically, and when selected manually, it never gets the "heart" icon.
Uploading an album that has only PDF's and THM's fails to create a profile page entry.
The user needs to manually rename files with an extension that the O/S thinks is something else (in my case, it thinks it's a LibreOffice config file).
Add a PDF/THM to a project in Tiger, for example, coupled with Link to originals. Then view the album. Fails miserably.
It's still needed, for PDF's, audio files, and sometimes videos, and would be useful for pano's (especially the equirectangular ones, which have terrible thumbnails), but can't be used because of file name collisions (the mydog.jpg 360 pano needs a mydog.thm thumbnail, but that would become mydog.jpg in the output, with predictable results).
The whole thing needs a rethink. Without having to rename files manually, it should be possible for a user to designate a representing image for any AO, and have the core take care of keeping things straight. I haven't thought this through, obviously....
I'm thinking of some sort of scheme where, in edit mode, there's an Add representing image button, with a file chooser. The chosen file gets stashed in .jalbum somewhere, hooked to the AO to which it applies. The core then uses that stashed file for creating the thumbnail and the slide image (for things like a poster image for an audio file). File naming would be dodgy - it needs something that isn't easy to break. Matching the base file name of the AO is just too risky. Maybe something like mydog.repimg.jpg.
The even nastier aspect of a rewrite is that trying to maintain compatibility with the existing THM mechanism might be damn near impossible. It would require some sort of "convert this whole project" tool to clean it up.
And some of the skin "fixes" would have to be replaced - my skins take care of the Link to originals problem by themselves, simply by detecting the problem and copying the needed file to where it belongs (that problem does not afflict THM's that are hooked to videos, BTW - it's only PDF's and audio files that fail).
One odd thing, which might not be new as I don't much use thm's is that in the thumbnail contextual menu the 'Use as folder thumbnail' is not available for the PDF.
Another is setting a jpg as the thumbnail and then, with no current theme image, dragging the PDF to the theme image. That works fine, but now if I drag the PDF to the folder thumbnail box it shows there OK but is removed as the theme image.
Defaults and skin used make no difference. Still not yet got it to fail though.