Photo roll kills small Server-CPUs

[tackin]

Initial Checklist

• I understand this is a bug report and questions should be posted in the Community Discussions
• I searched issues and couldn’t find anything (or linked relevant results below)

Bug Description

Please make the Photo roll -extension optional with enable/disable via environment-var as it produces a long lasting very high load on small CPUs. Else Opencloud becomes unusable on small CPUs/Raspis.

Reproduction Steps

Tested on latest opencloud-rolling 4.1.0.

Expected Outcome

Add a switch to disable the feature if not needed.

Actual Outcome

Extreme CPU loads on web-views.

[JammingBen]

Are you sure it's the photo roll causing this? What give you this impression?

Extreme CPU loads on web-views.

Please elaborate a bit more in which situations you notice this. So I assume the CPU spikes are only notable when you open an image? And it goes back to normal when closing the preview app? How does it behave when hiding the photo roll via the controls at the bottom?

[tackin]

What do you mean by "elaborate a bit more"?
Having 50 picts in a folder and open one pict starts the process of producing previews for all 50 picts in that folder to fill the roll which leads to skyrocketing load for 15+ mins.
But if it is even "only" 5 mins of high load it makes opencloud unresponsive for the user, leading in even more clicks around and more queued requests for even more load.
And we have folders with 100+ picts as well.
We switched form a slow nextcloud to a quick and responsive opencloud which is working great on lowend-hardware. And this new feature is simply pur poison to all your efforts to be the "better and faster alternative".
I don't like to throw new hardware-resources on a thing/problem/bling-bling if it can easily be avoided.

There is no essential need to torture every single Opencloud-host-CPU with a nice-to-have-but-can-perfect-life-without-it-feature.
I just need to keep 5000+ files in spaces to be available for the users over a 1000MBit-LAN which works perfect with opencloud so far for all of us.
Please keep the code lean!

[JammingBen]

What do you mean by "elaborate a bit more"?

Well, it usually means giving more context. In case of "Extreme CPU loads on web-views." I felt that was needed to correctly analyze the problem. Hence the questions I asked.

I'm still questioning the root cause because all the photos were loaded before this change as well. They were just not rendered in the browser, which happens client-side. Meaning the server load should be exactly the same as before. Of course there may be another cause for high CPU usage. But that needs analyzing.

Please keep the code lean!

That's what we're certainly always trying. However, new features do not necessarily equal "unclean" code, even for things that are eye candy.

[Stylishly8742]

Please keep the code lean!

That's what we're certainly always trying. However, new features do not necessarily equal "unclean" code, even for things that are eye candy.

That wasn't a typo, more a statement about feature creep.

[tackin]

I switched from "opencloudeu/opencloud:latest"(4.01) to "opencloudeu/opencloud-rolling:latest"(4.1.0)
In 4.0.1: every pict-folder stays responsive, no load.
In 4.1.0:
I opend a pic-folder in the webbrowser: normal no load:
I open a pict: Host got unresponsive. SSH showed me very high load. Closing the pict and leaving the pict-folder dropped the load after a while. Every other space with many PDF and other docs worked normal. No load.
Switching to an other pict-folder: no load
Open one pict: high load again.
Hiding the roll: no effect

Not only that it produces high load, it also "corrupts" web-views. Got errormessages of picts not "available" and picts not rendered in roll-previews. but the picts are ok. A click to the same "corrupt" pict after some time: it opens just normal

Switching back to stable 4.0.1: Every thing is smooth. No corrupted pict-files,
Previews in tiles-view: normal.
Picts: show up fast on click-on-pict in webbrowser

So my guess: the Photo-roll is bad eye candy for my CPU. ;-)

I don't want to stop you from inserting nice new features to opencloud. I just beg to please make it selectable.

[JammingBen]

That's the kind of detail what I was after - thanks! 👍

We need to do some analyzing on what's the issue exactly. As I said above, the images we're preloaded before. There might be some other (server) issue. Adding an option to disable the feature would only be a workaround, something like this shouldn't cause anything like you're describing, so I'd really like to get to the root cause. Let's see what I can find out.

That's what we're certainly always trying. However, new features do not necessarily equal "unclean" code, even for things that are eye candy.

That wasn't a typo, more a statement about feature creep.

I didn't interpret it as such. New feature != un(c)lean code. 2 different things 😉

[tackin]

Ah! Well if the picts are rendered client-side for a roll that is even worse!
So we need to push hunderts of MB (all pict in a folder in highres) through the DSL to the Client for every pict-click on a single pict in a folder, so that this client-browser can render the roll.

Please tell me that this is not true!

[JammingBen]

The client doesn't render raw images, no worries there. The preview service in the server is scaling and compressing the images quite a bit for display. Meaning a 50MB RAW image does not result in 50MB being transferred from the server to the client when viewing it. Only when downloading of course.

[Stylishly8742]

More details / reproducability infos:

1 - In the web interface, open a folder containing images
2 - Preview thumbnails are being generated (expected)
3 - Click on a photo, which starts the photo roll view
4 - A different set of preview thumbnails for the left-side preview is being generated (not expected). At least it looks that way from the container usage pattern.

It also seems like the left-side roll previews are being generated all at once, not page-wise as for the folder view, which makes the effect even worse in folders containing a large number of images.

This can also be seen when the folder contains so many images that the folder view is split into multiple pages. Even with the completed photo roll previews, the previews for the e.g. second page of the folder view will be newly generated once you switch pages.

This is on rolling 4.1.0

[tackin]

The client doesn't render raw images, no worries there. The preview service in the server is scaling and compressing the images quite a bit for display. Meaning a 50MB RAW image does not result in 50MB being transferred from the server to the client when viewing it. Only when downloading of course.

But that is nevertheless a big problem for the usability of opencloud on low-end-hardware and smaller DSL-Net! You burden the CPU and the DSL with useless data-load no matter how you do it in detail.

[tackin]

More details / reproducability infos:
4 - A different set of preview thumbnails for the left-side preview is being generated (not expected). At least it looks that way from the container usage pattern.

The solution could be: reuse the previews of the tiles-view to make the roll. They are rendered anyway and also already transfered to the client in tiles-view.

[JammingBen]

1 - In the web interface, open a folder containing images
2 - Preview thumbnails are being generated (expected)
3 - Click on a photo, which starts the photo roll view
4 - A different set of preview thumbnails for the left-side preview is being generated (not expected). At least it looks that way from the container usage pattern.

That's actually expected because the thumbnails are being loaded in thumbnail-resolution. You can't use that for display.

The concrete to-do for the client is to limit the amount of pre-loaded (=cached) images, preferably to the amount of images in the viewport. Which shouldn't result in more than a hand full. I thought we had that at some point, but it's definitely not working that way right now.

And it still doesn't explain why the issue occurs just now...

But that is nevertheless a big problem for the usability of opencloud on low-end-hardware and smaller DSL-Net! You burden the CPU and the DSL with useless data-load no matter how you do it in detail.

You're describing the typical pain point with loading everything on demand vs loading things beforehand to allow for a faster and better navigation/UX. We found most of the time, the solution sits somewhere in between. Just have to find that line.

[Stylishly8742]

Aw hell... it's even worse than I thought: the folder view will lazy-load the thumbnails for the visible images on that page, that's fine:

10.0.0.159 - - [17/Dec/2025:16:08:58 +0100] "GET /remote.php/dav/spaces/b1b75d72-ee2a-4af2-adaa-49573e16b5dc%24a538939c-9c44-4dc1-8a62-a6e3c0639a03/Bilder/2013/JPEGfilename.JPG?scalingup=0&preview=1&a=1&processor=fit&c=cafb20c045b97590c1fb4d82331549ee&x=1000&y=1000 HTTP/3.0" 200 84695 "-" "-" 28446 "opencloud@docker" "http://172.23.0.4:9200" 525ms

Once you enter the photo roll view, the browser will load what appears to be all the photo roll previews, every time you enter the photo roll view. This leads to a huge spike in server usage and network usage. I get hundreds if not thousands of lines like these:

10.0.0.159 - - [17/Dec/2025:16:10:51 +0100] "GET /remote.php/dav/spaces/b1b75d72-ee2a-4af2-adaa-49573e16b5dc%24a538939c-9c44-4dc1-8a62-a6e3c0639a03/Bilder/2013/filename.JPG?scalingup=0&preview=1&a=1&processor=fit&c=4b0b6c25b6a2a6687e9a64e98b33dce6&x=1920&y=1920 HTTP/3.0" 200 882877 "-" "-" 29872 "opencloud@docker" "http://172.23.0.4:9200" 658ms

Close the photo roll view and click on a different image? Same story, hundreds of lines loaded from the server, NOT being re-used from the browser cache as are the folder view thumbnails.

Oh yeah, and the miniature photo roll previews are loaded as 1920x1920...

More disturbing news: if you enter the photo roll view in a folder which didn't have previews until then, it'll generate the whole photo roll and will not stop that task, even if you navigate away.

So clicking on "Personal" on the left: spinning indicator until the preview generation for that previous photo roll is done.

[tackin]

You're describing the typical pain point with loading everything on demand vs loading things beforehand to allow for a faster and better navigation/UX. We found most of the time, the solution sits somewhere in between. Just have to find that line.

I personally would search for that line in .env
OC_WEB_PHOTO_ROLL_ENABLE=false

(Sorry couldn't resist 😉 )