-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: PDF previews don't work after upgrade to 27 - Error 400 #38911
Comments
I'm having this issue but on a Hansson IT VM. |
I think that the problem is with the "preview" parameters "x" and "y". When I enter a folder with PDFs Nextcloud tries to get a preview icon for each PDF. The call is this: If I test this call manually I get an empty json content-type. But if I execute the call changing "x" and "y" for some bigger number like 512 x 512 or more I get the right icon with Also if you open the PDF detail view of the PDF it shows the correct preview image in the upper corner. This call has |
I am also facing this issue with the official docker image. I am using imaginary if that affects anything. |
I just tried to find the numbers for x and y where the preview starts to work: its 257. However, the image file in the response always has 793 x 793 pixels, regardless of the provided x and y values. |
Yes, the previews of .HEIC files also do not load with the parameters &x=250&y=250&forceIcon=0&a=1. |
At least for me this only happens with Imaginary enabled (see #40652 (comment)) |
Yes, I can confirm. Thank you for pointing me in the right direction. I checked my standard config again, and I forgot to remove "preview_imaginary_url" . Everything is working again now. Thanks, you've been a great help; I wouldn't have looked so closely otherwise. |
What are your Imaginary |
Just the basics. So the Entrypoint from the Dockerfile. I just added the other recommendations from your other post:
I'm now testing it... Edit: No changes... As soon as I re-enable Imaginary in my config, the calls for the previews start to fail again with error code 400. In my debug output of the imaginary service, I don't see any requests. |
@solracsf where's the function/setting in the code for generating 250x250? Since 257 works, maybe we/you should change to that? Sorry, I don't know any PHP. |
Shouldn't we try to fix the origin of this issue instead of just working around? What if the problem starts to show with values smaller 260?? |
Sure, but a good starting point is finding out why it works for some, but not for all. brave_cOpArTdl9I.mp4 |
May be I found something. if I enter a folder with some PDF, then looking into the Imaginary log, it shows nothing, but when I open file details, Imaginary shows the operation results in the log. EDIT: almost confirmed. I've made a little change and now I have PDF preview working on Imaginary. Look at this: server/lib/private/Preview/Generator.php Line 145 in bcda331
I've changed 256 to 249 on both dimensions and now calling to Imaginary with 250 x 250 is working. |
@solracsf Does it also work if you use the list view? |
For those having the problem, can you patch this line: server/lib/private/Preview/Generator.php Line 254 in d070d5e
so it reads
|
@solracsf That solves it for me! |
This solves #38911 cc @szaimen @solracsf Signed-off-by: Daniel Hansson <[email protected]>
How are your PDF previews generated than? 🤔 I can see the Imaginary calls in my instance. As you can see, the
|
Well, if you have different previews generators it can get hard to debug your setup 😆 |
So in the end your proposed change fixes the problem also for this mixed setup. Which is good to know... Why it only appears if Imaginary is configured even if it's not used for PDF previews when Onlyoffice generation is enabled, still isn't clear to me. But as long as everything works, I'm fine with that 👍🏻 |
I just tested.
In other words, the fix works for Imaginary. I also noticed TIF previews are now working which wasn't working before. |
One thing I noticed now though, previews in the activity pane are still not generated: https://cloud.whatever.nu/apps/theming/img/core/filetypes/application-pdf.svg?v=7e8a4c67 |
No problems there for me |
Try this #38911 (comment) |
Please note, the code only fixes Imaginary, well, because it only targets it. In other words, developpers had put a condition that, if Imaginary is installed (correctly) and the asked preview is less or equal than 256, it should only generate that size, instead of all sizes normally generated when a preview is asked (by the comments on that file, for "performances reasons"). There is a problem in the code because it first try to get a cache (an already generated preview in other words), which doesn't exist for a first asked preview (obviously), but it returns 400 instead of 404 because $width and $height are not in the expected range. So, the fix bypasses not only a 404 (expected) but also a 400 (possible) and generate a new preview as cache returns "false". The same logic is already present on that same file if you read the code. For me, the best solution would be to remove that "performance" condition and just let Imaginary generate all sizes, just like any other provider. 👍 Less error prone. |
That didn't help, tried to set as low as 1 X 1, but nothing. |
Fine with me, and a better solution also in general. That's how preview generator works IIRC. |
I vote for a second PR. |
I'll let core developpers take decisions here ;) This is the code I'm talking about (to be eventually removed): server/lib/private/Preview/Generator.php Lines 142 to 157 in d215d80
|
A follow up on #40670 Based on discussions here: #38911 (comment) This fixes the case were not all previews are generated, for example in the activity view: #38911 (comment) Signed-off-by: Daniel Hansson <[email protected]>
Now it's in a separate PR since it's two different issues. |
A fix has been merged, this issue can be closed. |
A follow up on #40670 Based on discussions here: #38911 (comment) This fixes the case were not all previews are generated, for example in the activity view: #38911 (comment) Signed-off-by: Daniel Hansson <[email protected]>
A follow up on nextcloud#40670 Based on discussions here: nextcloud#38911 (comment) This fixes the case were not all previews are generated, for example in the activity view: nextcloud#38911 (comment) Signed-off-by: Daniel Hansson <[email protected]>
Bug description
On one of my instances PDF previews do no longer work after upgrading to NC 27. On both my other instances it works as expected.
The failing one is using the official Docker images. The other two instances are classic installations at shared web hosters. Other differences: DB (pgsql <-> mariadb, redis <-> non redis)
PDF previews work with Imaginary disabled, so I think it's related to Imaginary.
Also, preview generation works for
x >= 257
andy >= 257
Steps to reproduce
Expected behavior
See previews of files
Installation method
Community Docker image
Nextcloud Server version
27
Operating system
Other
PHP engine version
PHP 8.2
Web server
Apache (supported)
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 22 to 23)
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Couldn't find anything in the logs, even with Debug mode
Additional info
https://cloud.domain.tld/core/preview?fileId=280976&c=bb75d279726eb8ef826eb9764852a2a1&x=250&y=250&forceIcon=0&a=1
Response code: 400
Response: []
The text was updated successfully, but these errors were encountered: