Migrate preview generation to async job execution

[LukasReschke]

The preview generation should happen using cron (preferably only the system cron) instead of happening on demand. - Currently we have a lot of users complaining about the performance just because preview generation is taking ages.

\cc @georgehrke
@karlitschek FYI

[LukasReschke]

And yes, I know that this is not possible with encryption, but the cronjob could just check whether the instance is encrypted or not.

Just because there is one use-case where it doesn't work shouldn't prevent massive speed gains on other use-cases ;-)

[LukasReschke]

Actually, we should not remove the on-demand generation but add another cronjob that does the generation already before in some "common" sizes (i.e. retina and non-retina).
If the user visits the folder before the cronjob happened the on-demand generation would happen, otherwise the existing pre-generated thumbnails would be shown.

[karlitschek]

I'm not really sure how this would improve the user experience. A background job is not faster with generating the thumbnails neither is it done necessarily at the optimal time. I assume people keep on suggesting a background job because the old on demand generation was blocking the UI which is horrible. So perhaps we should wait if people are more happy with the behavior of 7.0.3

[georgehrke]

I agree with @karlitschek here. Let's wait for user-feedback from 7.0.3.
If people still experience performance issues with 7.0.3 this is definitely something we should consider for ownCloud 8.

a few things we should discuss when considering implementing this:

• breadth-first or depth-first. (I'd vote for breadth-first)
• sizes for caching: maybe also 1024x1024 for public sharing

[LukasReschke]

Setting to ownCloud 8 and triaging. - Let's close this if nobody complains, if not let's see what we can do.

[ronnicek]

@karlitschek it's easy.. set up Raspberry Pi /w Owncloud and load gallery with some photos :)

[budulinek]

Hi, first of all thanks a lot for considering the issue.

@karlitschek the problem is not the UI, but the preview generation.

I have just installed 7.0.3 and the UI itself is really quick. Good job. But the preview generation takes ages on slow machines (15 images take cca 2 minutes). I have a router running Openwrt (1200 MHz, 2GB RAM).

Background job is not faster. I agree. But once the process is over, all thumbnails are ready to be shown. And they do not have to be generated on-demand.

With the cron job, the user (server administrator) can decide when thumbnails are generated. Of course, it is difficult to choose optimal time. But it will be up to him to decide which time is optimal for the thumbnail pre-generation.

My suggestion:

• create new php file, do not use existing cron.php for thumbnail pre-generation
• the new php file would trigger preview generation for Gallery and for Files app
• server administrator can schedule the preview generation using crontab
• server administrator can set the priority of the thumbnail generation with nice
• If the user visits the folder before the cronjob happened the on-demand generation would happen, otherwise the existing pre-generated thumbnails would be shown

[oparoz]

• Define a max size and expose it in the admin area perhaps Introducing the maximum size preview #13674
• Suggest all apps use that setting for performance reasons.Preview providers should take maxX and maxY into consideration #13607
• Add a batch processing button for users so that they can upload all the pics from their camera, press the button and come back later to check the result. Users don't know when the cron job will run and are less likely to get frustrated with the gallery loading pictures slowly if they know they simply have to wait 30 minutes for all previews to get generated