Same image multiple times fail when compiling ebook

Hi,

if I include multiple images with the same exact content, then only one will be included in the ebook, the rest will show a broken image.

How to reproduce: create an image, let’s call it “a.jpg” and simply copy/paste it in Windows, to create “a (Copy).jpg” or rename it to “b.jpg” it makes no difference. Now include both “a.jpg” and “b.jpg” in the document (two different files, but their content is exactly the same). Compile a kindle ebook. It will give errors that files with extremely strange names are not found. And the end result will be that only the first image is included in the mobi file.

Workaround: make at least a pixel modification in the second image, so it’s not exactly the same, and it will be included correctly.

I would think that this has to be unrelated to the similarity in the content of the images as that is something Scrivener just would not know. It’s probably a memory issue so try reducing the size of the files or try linking to the images rather than placing them in the document. See section 15.5 in the manual.

Definitely not a memory issue because when I add the same number of images with different content (I used the same images, with small “1,” “2,” “3,” etc written on them), everything works fine.

The finename the compiler complains of not finding looks to be a hash of some kind. My first reaction is that it assigns a hash to the image content and uses that as an internal name. When it comes across two same hashes (same image content) but different filenames, it doesn’t know what to do. But since I have no idea what goes on in the background, this is just a wild guess. The error was consistend and always reproducable so it should be easy to replicate for the dev team.

Now that we have a Release Candidate, anybody want to… I dunno… maybe look through the submitted bugs? :smiley:

With RC3, I am no longer able to reproduce this issue. This was either fixed, or something else got changed that had a side effect of fixing this issue as well.

Either way, this report can now be considered fixed in RC3.