-
Notifications
You must be signed in to change notification settings - Fork 58
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
How to config? How to reclaim space? #94
Comments
First of all, the most annoying thing that was happening here was that I had max_x/y set to 512 at some point and because of that many of my previews were still opening in 512 pixels even though I had it set to 2048 and null for a long time at my config. I really wanted to reset everything so I could have the bigger previews for those. The other problem was that my data folder doubled in size, as mentioned (even though I was browsing in 512px). To "reset" the preview cache
A command to do this would still be nice and needed. I am still not sure on the optimal way to use the generator though. I was checking the image sizes generated when browsing and previewing some of my folders and it seems like the 32x32 and 256x256 are the most used for a desktop interface. So I tried using that for squared thumbs and null for the other two but I still got some extra thumbnail sizes generated. Maybe I will try to hack it to those 2 sizes only later. At this point I gave up on pre-generating. I just browsed the main folders from gallery a little bit so it would pre-generate that and have a fast base tree. I wonder if we could pre-generate exactly the same sizes needed for the browser on list / thumbs views. Maybe even use the same functions from there? Not sure... Cheers! |
You might be interested in this https://ownyourbits.com/2019/06/29/understanding-and-improving-nextcloud-previews/ |
Is there any work done to keep preview files from entering oc_filecache table in the SQL db? Ideally, if they indeed are needed, perhaps a second table or second db for previews would be preferred. It really slows sql performance down a lot. |
I think this is an related issue: #162 (comment) |
Do not delete the preview folder, only the contents of the preview folder.
|
Hello, |
Hi!
Say I apply these settings
And my
config.php
hasOR
And then I run
generate-all
Would the generator set the
'_max'
file to 128 pixels only and then just use that size as maximum even when I click to open an image? Or is just for pre-generating and nothing else and then the bigger image will be generated when clicked? I am but confused because I got some mixed results here, but I am guessing the browser cache was doing its thing.What would be the recommended settings for a big install with lots of images?
We want to be able to browse it fast and have the best full-screen experience, but we would like to avoid having 30+Gb (still processing) of preview images data (which also goes to the backup, btw).
And then there is also the question if it is safe to remove the preview files and/or folders to reclaim that space, which I already asked on core. nextcloud/server#5263 (comment)
I would probably prefer to make some simple bash scripting to remove just some bigger sized PNGs so I don't have to reprocess everything. That is easy if there is no problem with the database and other stuff.
In any case, because I was testing different configs as well, I can see many different preview images above 1024px for some files, which is probably the reason for such a big footprint.
I would prefer to have just the smaller sizes pre-generated (for menus and icons) and let the big stuff be done as needed. Can this be done with the config above?
Edit
Also, what does
pre-generate
really do? It runs in 1s and does not seem to create any files here.generate-all
scans everything (for days) and sucks the processor and creates the pngs, butpre-generate
does not seem to do anything.The text was updated successfully, but these errors were encountered: