"In general" the behavior does seem consistent with "there are attachments in the database which aren't being found in the actual /files directory." What is actually seen when loading one of the problem pages is that trying to pull a thumbnail for one of the images will actually return status 500 (web server unable to complete request), while the others return a more normal 404 (not found) status. But it's not consistent which one will return 500 versus 404.
For example in the http://www.973-eht-namuh-973.com/forum/ ... =1&t=14820
thread, I can get 500 for file.php?id=4095 and 404 for file.php?id=4096 and all the others; but on a reload of the page, file.php?id=4096 may return 500 and file.php?id=4095 and all the others are the ones that return 404.
So maybe there is a clue in the web server and/or PHP error logs, which is being recorded during the 500 status event. I'm thinking of things like maybe there will be an error or call stack that implicates one of the additional extensions that are in use, or similar.
Aside from that, I agree with what Steve suggested too, regarding tracking down one of the "file ID to real file name in /files directory" mappings out of the database, and determining whether that file exists, whether that file has some kind of unique permission applied to it, whether it's content seems corrupt or maybe zero-length now, etc.
The files in the /files folder are not necessarily .jpg files. I you look in the database attachments table, you can correlate real filenames to physical filenames to determine which, if any, are .jpg files and test there viability by adding that extension and browsing to them.
For example, in this screen shot here, I'm looking at attachment ID 1 out of the phpbb_attachments table, and can see that this attachment ID has a filename of "2_47ca94c7e0d7f7dd631a1a1b0b45c296", and the original filename was "sometext.png". So I would go verify the existence and security on /files/2_47ca94c7e0d7f7dd631a1a1b0b45c296, and then make a copy of that file and rename it to "sometext.png" and try to view the file to make sure it's not corrupt or empty.
In your case, you would have @robbell
do that for at least attachment IDs 4095 and 4096 since we saw those as being affected, as well as any other affected attachment IDs you wanted to check.
What happens next probably depends on whether you find that the files are simply missing, or are all wrongly secured and preventing access, or are all corrupted, or all seem to be 100% fine, etc.