I can't see my gallery on Android

[alexandre-leng]

⚠️ Before posting ⚠️

• [x] This is a bug, not a question or an enhancement.
• [x] I've searched for similar issues and didn't find a duplicate.
• [x] I've written a clear and descriptive title for this issue, not just "Bug" or "Crash".
• [x] I agree to follow Nextcloud's Code of Conduct.

Steps to reproduce

Subject: Media display bug in Nextcloud - October 2024

Hello,

I would like to report a bug I encountered in the Nextcloud app related to media display. When browsing my photos and videos for October 2024, I only see grey placeholder icons instead of the actual image previews.

The images are not loading properly and remain stuck with the default icon, with no preview available.

Here are some additional details:

Nextcloud version: 3.29.2

Device used: Xiomi poxo x4 pro

Stable internet connection (4G+/Wi-Fi)

Date and time of the issue: October 9th, 2024

Could you please look into this issue and let me know of any solutions or fixes?

I have allowed all permissions

Best regards,

See in attachment Alexander

Expected behaviour

It should have a thumbnail of the photos displayed

Actual behaviour

Photo thumbnails are not displayed

Android version

13 TK1

Device brand and model

Xiaomi poco x4 pro

Stock or custom OS?

Custom (explain in "additional information")

Nextcloud android app version

3.29.2

Nextcloud server version

1

Using a reverse proxy?

No

Android logs

No response

Server error logs

No response

Additional information

No response

[alperozturk96]

Could you try with latest version?

[orionp13]

Hi, I simply configured the photos and linked the folder to Nextcloud Photos, and it resolved the bug. It can be great if miniature can be displayed even if it not linked.

[joshtrichards]

I simply configured the photos and linked the folder to Nextcloud Photos, and it resolved the bug.

What do you mean by "configured the photos"? Were previous turned off server-side?

[DaleBCooper]

Could you try with latest version?

Same problem with latest 3.30.1release. It used to work and I don't know when it started to fail (not using it on a daily basis).

Server log (Nextcloud30.0.1) :

"GET /index.php/core/preview?fileId=0092443151cda369ab867&x=540&y=1078&a=1&mode=cover&forceIcon=0 HTTP/1.1" 404 2 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.30.1" [...]

[himpierre]

maybe related to #13515

[github-actions[bot]]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[joshtrichards]

/index.php/core/preview?fileId=0092443151cda369ab867&x=540&y=1078&a=1&mode=cover&forceIcon=0

@DaleBCooper What happens when you try to open that URL (e.g. https://domain.tld/index.php/core/preview?fileId=0092443151cda369ab867&x=540&y=1078&a=1&mode=cover&forceIcon=0 from a logged into your Nextcloud browser?) A 404 indicates a server-side matter. Please check server logs too.

[DaleBCooper]

/index.php/core/preview?fileId=0092443151cda369ab867&x=540&y=1078&a=1&mode=cover&forceIcon=0

@DaleBCooper What happens when you try to open that URL (e.g. https://domain.tld/index.php/core/preview?fileId=0092443151cda369ab867&x=540&y=1078&a=1&mode=cover&forceIcon=0 from a logged into your Nextcloud browser?) A 404 indicates a server-side matter. Please check server logs too.

Sure it throws a 404, too. But: If I remove the leading zeros and the random string (aka instance id) from the fileID I get the correct preview image:

/index.php/core/preview?fileId=924431&x=540&y=1078&a=1&mode=cover&forceIcon=0

Before you ask, the instance id in config.php is correct and corresponds the the appdata folder. I guess otherwise there would be more problems. ;-)

I have an old test installation (upgraded to latest NC 30.0.2) where both URI work (e.g. fileId=00007001oco7qtfh9yyg and fileId=7001).

The only difference between the two installations is: The production uses a data folder outside web root where the test installation uses default settings where the data folder is located inside the web root. May this be the cause?

[DaleBCooper]

Additional notes: the leading zeros don't matter, fileId=00924431 works also.

I wonder why the android app appends the instance id the the file id? Accessing the web interface via browser does not show this behaviour. All request are done with the real plain file id.

Edit: another observation, if I access folders containing images with the android app the requests are done without leading zeros and appended instance id:

"GET /index.php/core/preview?fileId=924431&x=256&y=256&a=1&mode=cover&forceIcon=0 HTTP/1.1" 200 25190 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.30.5"

But if I try to open the image it fails cause this request is done with leading zeros and instance id like above.

[joshtrichards]

Found it I'm pretty certain! Thanks. That was helpful!

Wrong in doResizedImageInBackground():

https://github.com/nextcloud/android/blob/cff4973f3579b635fb2f449521a08471700a3989/app/src/main/java/com/owncloud/android/datamodel/ThumbnailsCacheManager.java#L1402-L1404

Correct in doThumbnailFromOCFileInBackground()

https://github.com/nextcloud/android/blob/cff4973f3579b635fb2f449521a08471700a3989/app/src/main/java/com/owncloud/android/datamodel/ThumbnailsCacheManager.java#L718-L720

local id = just the file id (the oc:fileid DAV property) remote id = file id + instance id (the oc:id DAV property )

[joshtrichards]

@DaleBCooper:

I have an old test installation (upgraded to latest NC 30.0.2) where both URI work (e.g. fileId=00007001oco7qtfh9yyg and fileId=7001).

The only difference between the two installations is: The production uses a data folder outside web root where the test installation uses default settings where the data folder is located inside the web root. May this be the cause?

That shouldn't work officially, but based on the server code I suspect it can work sometimes because that value comes is as a string but it used as an integer. That would have the effect of dropping the instance id from it in some cases... I'll see if there's a way to make that more robust on the server-side.

Might also explain some of the inconsistent test results I saw mentioned in some of the discussions related to a prior PR in this code area in android-library. So thanks also for mentioning that detail. :)

[DaleBCooper]

Found it I'm pretty certain! Thanks. That was helpful!

I'm glad I could help. Thanks a lot for taking a look into this issue and fixing it!