GIF Thumbnail creation fails, breaking the image picker window #5029
Comments
|
I've submitted a pull request that tries to fix it on #5030 |
|
Hi @bytebone,
|
|
Hey Dan,
Heres a quick list of gifs that I tested:
I cannot see a specific pattern in these results. I'm curious to hear your opinion. If you have an idea where else I could find more helpful error logs, let me know. In hindsight, I also want to note that we've upgrade from 23.12.2 straight to the newest 24.5.1. GIF upload has not been an issue on 23.12.2 as far as I can remember. Since I cannot bear the dataloss from a database rollback (lots of edits since the upgrade), I am unable to go back to that working version. |
|
Thanks for the info @bytebone, Looking just at the difference between the working earth GIF and the provided drippy zig-zag gif, although a similar filesize and dimensions, the latter appears more complex. Opening in GIMP (as a rough test) the drippy zig-zag is 215 frames at 200MB of memory overall vs the earth having 44 frames at 8MB of memory. Therefore I think this may be a memory exhaustion scenario during resize attempt. |
|
Interesting. After setting it to 512M, some of the formerly failing gifs can now be uploaded, but still not all. When trying to upload the 41.gif from above, i see a notable spike in CPU and RAM usage while BookStack attempts to extract a thumbnail, but after ~2.3 seconds I still get the 502 error response with the same behaviour as before. After doubling yet again to 1024M (equal to half of the total RAM on this small VPS) the 41.gif is still too complex for the thumbnail extractor. I can see the RAM filling up roughly by 1 GB - as soon as it does, the BookStack task fails and the issues continue as seen before. How can the extractor require over a gigabyte of RAM when working with a 900 MB gif? By doing this testing, I've found that the error flow described before only applies when the memory_limit is filled without hitting the machines RAM limit. With a memory_limit of 1024M, the machines RAM is full before (or at the same time as) the PHP limit, leading to the following flow:
|
On my dev instance that I'm testing on there's a PHP I think this GIF is particularly problematic due to the sheer amount of frames (over 200) at reasonable resolution. Whatever's going on here, it's probably more sensible if we avoid handling animation during this process and instead just create a thumbnail based upon a single frame. |
I fully agree, and since its only a preview for the image picker (presumably the gif gets natively rendered by the browser whenever its shown, without the need for processing by bookstack) IMO its perfectly fine to take the first frame of the gif and pull that out as the thumbnail. Right now I cannot really tell if this is something you'd consider fixing soon-ish or some time later down the road. If this isn't important enough in the grander scheme to fix quickly, do you think some better error handling could be done in an update soon, so that the app doesn't behave so crazily whenever it happens? Having to dig around in the filesystem whenever a gif fails to generate a thumbnail gets tedious over time... |
|
I'll assign to the next patch milestone. No time assurance for when that would be but should not be too far in the future. |
|
Hello. I'm running into this issue with animated .gifs as well. The actual file size of the .gif is tiny, but it is also around 200 frames. |
.gif){kind=link}
Changes GIF image thumbnail handling to direcly load via gd instead of going through interventions own handling (which supports frames) since we don't need animation for our thumbnails, and since performance issues could arise with GIFs that have large frame counts. For #5029
|
I've now updated our handling to only resize via native methods without animation support, via commit 3406846, with tests added to cover. This will be part of the next upcoming patch release so I'll therefore close this off. |
|
Just tested the newest release, reset the memory limit by commenting out the added line (assuming the default is 256M), and uploaded the GIF that broke everything earlier, as well as a huge 9 MB gif. Both work very fast, instantly displaying in the document and image picker. Great work, thank you very much for the fast assistance and fix. |
|
Much thanks @ssddanbrown |
Describe the Bug
When uploading a gif, Bookstack often fails to extract/generate a thumbnail image. This is not communicated in the GUI or the realtime application logs. But it is visible on the filesystem, where the original file is saved, but no thumbnail gets created in the respective subfolder, and an error gets logged in the laravel.log file (see below).
Once this has happened, the image picker no longer loads any images and gets stuck on an infinite loading animation. In the dev panel, after about a second of the image picker being open, the gallery endpoint returns a 502 error code.
To resolve the issue, the original gif file needs to be deleted from the uploads folder. The image picker will load again and display a broken image item, which can then be deleted from the picker/database.
Steps to Reproduce
Expected Behaviour
Should be obvious
Screenshots or Additional Context
I am using the Linuxserver Docker image to run Bookstack, but by the nature of the error assume that its not an issue with their Docker wrapper, but with the core app.
Error Log:
Details
Browser Details
Brave 1.64.113 / Safari (Version unknown)
Exact BookStack Version
v24.05.1
The text was updated successfully, but these errors were encountered: