Normally, yes. But I donāt upload photos in the usual way. I have attached an external drive with a few thousand images and need an efficient way to produce the thumbs. In my case, I need a way to generate the thumbnails ābehind the scenesā or perhaps āon demandā.
This seems plausible. I do not know how new files on your HD are discovered by the files app, but maybe the discover could be the point of time where you create such thumbnails!? This could also decrease the amount of thumbnails to be created each time.
I use the āExternal storage supportā app, which works very well for me to access my files in File view. Accessing the external mount is transparentā¦ only the folder icon of the new drive is somewhat different in Files view. Everything else feels the same so far as I can tell (although I havenāt explored all the options).
My problem is that after I attach the drive, I cannot use Gallery view at allā¦ it hangs, or at least it appears to, and I cannot get past the root folder as the spinning wheel Iām sure is continuing to try (or failing) to create the thumbnails (thereās no feedback, so I donāt know what itās really doingā¦ I canāt find anything in the logs about it). Iāve let it continue with the āspinning circleā for hours, and still it hasnāt finished its work. Thus, I donāt think the moment of drive attachment would be the right point to generate the thumbs, at least not in the same manner as now.
This is why, at least in my case, Iād prefer to have the option of a separate or background or an āon demandā thumbnail creation. āSeparateā would be something like the ācreate-thumbnailsā feature mentioned in my earlier notes here. āBackgroundā means it could create the thumbs behind the scenes, but still lets me go into Gallery view for those other folders which already have thumbs created, without interference by the thumbnail generation process. By āon demandā I mean the possibility to generate the thumbs only when the specific parent folder is clicked on. In my case, that would seldom involve more than 40 or 50 images, in contrast to having to bulk generate the other several thousand at one go.
The other thing which just occurred to me is that for all the images I would need to make thumbs for, after they are created the cache would probably be enormous. Iām running mysql which works well at the moment, but I imagine the database and php configurations would need to be considered, too, for handling such large numbers of images and their thumbnails. An additional consideration would be what happens if the external drive is ejected or unmounted. For me, itās not an issue, since I am āpermanentlyā mounting an separate partition on the server drive, and will not really ever think about ejecting it. But Iām sure other folks might attach a ārealā separate hard drive.
Thanks for following up on this matter. Itās hardly a critical thing for the operation of Nextcloud/Owncloud, but solving it would facilitate the use of Gallery for those of us with mass quantities of images.
Mike
Quick question here. When using the occ command line to generate thumbnailsā¦ if the source picture(s) gets moved to a new folder within owncloud:
- Will a new thumbnail have to be generated for the source file after itās moved?
- If a new thumbnail does indeed have to be generated, what happens to the old one?
- Where are these thumbnails stored and under what type of naming convention?
Thanks!
Mike
No news?
Iām also trying to create thousands of thumbnails ā¦ no way, get this:
sudo -u www-data php ./occ gallery:create-thumbnails --a
[Symfony\Component\Console\Exception\CommandNotFoundException]
There are no commands defined in the āgalleryā namespace.
NC 11.0, Gallery 16.0.0
Hi
Iāve found that itās not necessarily the thumbnail generation that causes all of the problems (although I am experiencing the same issues mentioned above)
My folder layout for my personal photography from the last 15 years is roughly (in a local āexternal folderā):
Pics/
Pics/photos/
Pics/photos//
For reference, Iām running NextCloud 11 on apache2.4, php7.1, on an i7-3770 with 16gb ram, and 2x raided(mirrored) 2tb spinny disks
Just loading the top-level Pics folder, which only includes a single folder, but no photos, takes about 15 seconds, even on subsequent loads (i.e. after loading thumbs)
Loading the photos folder then takes about 40 seconds; then the thumbnail generation starts, async from the browser.
At a guess, itās doing a deep tree scan on every page load?
Thanks!
Seb
Thank you for this information. Can you please share when this should be ready in production?
+1. I just have a few hundred pictures and this section of NextCloud is impossibly slow.
this feature is badly needed. i have hundreds of photos in every folder and previews are tooo slow to load.
Agreed. The mobile gallery apps are very fast. I would love to be able to ditch Apple for storing my photos.
i installed the preview-generator-program from the āstoreā and (re-)generate all previews with a nightly cronjob. i have ~100GB of pictures and the cronjob takes ~150mins. the previews take up ~83GB (!!!) in /data/appdata_ocjecx05wt96/preview but the gallery really is amazingly fast with it (before that, it wasnāt useable at all.)
so if you have the diskspace and can spare some computing cycles, iād say itās really worth a try.
GOOD LUCK!
Enhance your config.php:
'preview_max_x' => 512,
'preview_max_y' => 512,
'preview_max_scale_factor' => 1,
Then follow this guide and your previews will jump up as popcorn.
~ 50GB of photos leads to 3,9GB of thumbs.
Hi!
Would you be so kind to tell where exactly mentioned lines of codes go in Generate.php and PreGenerate.php? I see a class (Generate and PreGenerate respectively) and canāt really decide in which function do they fit and what they will do (they possibly go into parseFile and processFile but Iām not a php wizard myself so not really sure).
Beside that, is it possible that you say a word about the difference between preview:generate-all and preview:pre-generate?
Thank you in advance!
hooger
Ok, for the second question I found this: GitHub - nextcloud/previewgenerator: Nextcloud app to do preview generation in the background.
It says:
preview:generate-all: Loop over all files and try to generate previews for themā¦
preview:pre-generate: Do the actual pregeneration. This means only for new or modified files (since the app was enabled or the last pregeneration was done).
the previews are very nice and fast once generated, but generation itself is pushing my system to its limits.
- the dir containing the previews has about the same size as the all the pictures together (110GB)
- generation takes 7+hrs/nite and increasing (cronjob) - even if there are no new pictures
- pre-generate does not work on my system (was finished after 2 secs but did not create any previews)
is there any way this could be fixed? if i delete the huge preview-dir i am afraid re-genration will take DAYS)
sudo /snap/bin/nextcloud.occ preview:pre-generate
is returning immediately for me too (it doesnāt appear to do anything)
I tried adding -vvv and still nothing is shown and it exits right away.
sudo /snap/bin/nextcloud.occ preview:generate-all
is doing something
You should make sure to use the update command in your crontab since it canāt take more then a second if there are no new images to generate.
This and opcache + local cache APCu are a must for big libraryās.
Of course first time generation can take a while depending on library size and processing power.
After that it should be mega fast.
One issue I still walk in too is that sometimes the gallery will just stop loading images in half way. It gets stuck on the loader at the bottom and when clicked I get jumped back one directory. This might be a Ajax problem, I will soon try other update methods.
Both the apps for Android and iPad keep giving major issues loading content off any types, but especially the image heavy directories make the app freeze. This is horrible unusable, which is a shame. I decided to just use the web app in most cases.
I feel like this might be a WebDAV issue, and nextcloud might have to think of a different engine for syncing files over.
Iām not sure if I had a similar issue or the same. When I scrolled through the pictures maybe the tenth picture took about 1 minute to load. Some pictures were fast again and suddenly another one was extremely slow.
I figured I had error messages about file locks in the system logs/ journal and that this was caused by Redis not working. Once I got Redis fully working, this issue stopped. No more files were locked by mistake or too long.