Possible issue with large image file sizes (specifically animated gifs)
Summary
Whilst viewing the following post (see below) I noticed that the included animated gif wasn't displaying (at the time of originally viewing this image, I was presented with a broken image icon and placeholder, which then was rendered to the Minds lightbulb image).
On further investigation, I found the following error:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 13989992 bytes) in /var/www/Minds/engine/Controllers/fs/v1/thumbnail.php on line 51
This error suggests that there is a maximum allowable image file size of 13.98MB (decimal - base 10 standard) / 13.34 MiB (IEC binary - base 2 standard). According to the above error, it seems that the original image has a file size that amounts to just over 134MB (128MiB).
Strangely, it seems that several other users can view the animated gif and there has only been one other user that has reported having a similar experience as myself (reported this issue within a comment which was added to the post).
So considering that this issue seems to be effecting only a minority of users, I am very intrigued and would like to gain a better understanding of what is causing this issue (I am wondering if this has something to do with either the end-users ISP provisions and / or Minds CDN provisions).
Steps to reproduce
If the image within the following post is not being displayed correctly then using Mozilla Firefox (or a Firefox derivative / Quantum rendering engine based browser) or Chromium (or Chromium derivative / Blink rendering engine based browser), view the resulting modal box (which should result in displaying the spinning "loading" wheel within the modal dialog box) then right click on the resulting rendering ("loading" image) and select the "view image" (Firefox) or "open image in new tab" (Chromium) menu item.
Platform information
Seems to be end-user platform neutral. Checked using x86_64bit versions of Mozilla Firefox (version 69.0.1 - Quantum rendering engine), Chromium (version 77.0.3865.90 - Blink rendering engine) and Midora (version 9.0 - Webkit rendering engine)
What is the current bug behavior?
See above
What is the expected correct behavior?
Animated Gif should be correctly displaying.
Relevant logs and/or screenshots
See above for error message.
Reference:
-
Original Post (also see the comments which I added within the @Perennial_Plant_YaMon / Tim Berrrrr comment thread)
https://www.minds.com/newsfeed/1040311506174717952 -
Corresponding Media File
https://www.minds.com/media/1033911929074921472
changed the description
changed the description
added scoped labels
added scoped labels and automatically removed labels
I am encountering the same issue.
Device: Note 10+ Browser: Chrome 78.0.3904.96
Placeholder is Minds Lightbulb, however drilling into the actual post it's just a black overlay.
- Developer
Should have been fixed with #1120 (closed)
Can you guys try Canary later today?
- Developer
And / or !397 (merged)
@benhayward.ben,
The animated GIF image that I referenced above is now being displayed within similar conditions as was used within my previous investigation, therefore I am closing this ticket.Edited by Mark Edworthyclosed
reopened
@benhayward.ben,
After testing this out with the following image that @luculent provided (which is an animated GIF that equates to 39.91MiB / 41.84MB), I noticed that whilst the file is uploading, the cached version is displayed but when completed, the image disappears and results with the file not being attached to the corresponding post (I have tested this via the same versions of Firefox and Chromium that I mentioned within this ticket's body).Considering this issue, I have reopened this ticket and the issue needs further examining and also due to the size restrictions that is imposed by Gitlab's issue section (which allows a maximum of 10MiB), I am providing a URL to the image file (plus a compressed .tar.gz which also contain the image file) for further testing purposes (btw, I tried compressing the file for the purpose of uploading to Gitlab using several compression techniques but due to the fact that the image file is fairly well optimised already, it wasn't compressing to a that much of a suitable size).
Reference:
Edited by Mark Edworthymentioned in issue minds#913 (closed)