More info:
the unsupported files seem to be .heic files from iPhone
I could solve the issue now by the following steps:
open the event
select and move all pictures back to photo stream
go back to photo stream
delete the troublesome event
all the glitches disappear as soon as the event is removed
I could recreate the event including the .heic unsupported format as follows:
create event by selecting only some of the pictures that are supported (JPG format)
select one of the JPG files as cover picture for the event
add unsupported .heic files to the event
No issue following these steps. It seems that .heic files give trouble when one of them is (randomly) picked as background picture for the new event.
Okay, I’ve been able to reproduce this by deliberately overwriting parts of a HEIF image with wrong data. The thing that would be interesting apart from the artifacts would be whether other applications are still able to display the images in your case, which would mean that we might have an issue in our image loading code.
Okay, the glitches will be fixed in the next release.
Do you know how the problematic images have been created (if shot on a phone, which model and photo settings), or can you maybe share an example image?
They were simply created by an iPhone. I’ve shared a sample to your email address.
Please let me know if there is any other information I could provide.
Thanks for sending the sample image and screenshot! It looks like the image(s) are not actually the source of the problem here, but it rather seems as if the cached preview/thumbnail data is corrupted in some form. Can you see if choosing Image → Renew Cached Data (and then possibly scrolling the view a bit to trigger a reload of the thumbnail) fixes the thumbnail(s) for the selected image(s)?
I’ve only seen similar issues in cases where the application crashed during an import or image analysis process. Ideally that should at worst lead to the cached thumbnail being considered missing and be subsequently regenerated - not in corrupted data. However, this is not easy to achieve without hampering performance, because for performance reasons, cache data is not written to disk immediately and also not necessarily in a known order.
I’ll try to reproduce something here by deliberately killing the process during imports and will think about ways to make this more robust without hurting performance too much - maybe something along the lines of a simple form of a separate journal, like journaling file systems use.
I was able to reproduce the issue with artificially terminating the process during an import and have now implemented a simple journaling facility for the metadata and thumbnail caches, so that from the next release on, such corrupted cache entries will be detected and recomputed. Performance-wise this also seems to be okay.
Meanwhile I’ve tried what you suggested, Image → Renew Cached Data, and it worked (and there was also no need to scroll to see the newly created thumbnail).
