When is a preview not a preview (Breaking user expectations)

So last night I found that the preview generation had got a bit out of hand, with them filling my entire disk (it’s not a huge disk at present) of my test box.

So, doing the logical thing that I think any normal person would do, I -

  1. Disabled the preview generator app.
  2. removed the previews
  3. updated the database to reflect this
  4. reconfigured the preview generation to limit their size to 256x256 tops (they’re only previews, right?)
  5. Re-enabled the preview generator.

Which worked - and I left it chewing through the previews overnight, which it did.

Except that my NC is now a basically useless potato-cam server.

Everything that displays the images uses the largest preview as the display version.

Why?! when I click to view it, I’m not previewing it. I’m EXPLICITLY requesting the file, NOT a preview.

Who on earth ever thought this was a clever idea? It totally breaks user expectations.

The user should never be shown a preview when asking for the actual file.

What if the file has actually gone missing, and the preview is all that’s left? the user will think their file still exists, even when it does not.

Or might configure things to save space and wind up ruining their UX (low res images).

I just dont get it. The original image is there. why not serve it up?

This seems to be affecting quite a few users (most complain about “blurry images”), with some reporting that nextcloud didn’t do this in the past.

Now I guess NC devs have ultra powerful machines, with 64 core CPUs and a coupel of TB of RAM, with a GPU to match… but I think most of your users dont.

I deliberately built a low end box for mine - I dont WANT something burning megawatt hours worth of energy and heating my house in summer, just to store some files with a nice UI.

Generating previews that include the actual max-size image is a DUMB WASTE OF TIME. Its literally duplicating the original image on disk at full res. Why? I didn’t want to double the size of my already overly large photo collection.

I don’t want to buy new disks just to store duplicate data.

Is this seriously a feature, not a catastrophically huge bug that wastes an additional 150% of the space your images take up? (incl. lower res previews as well).

And the thing is - when basic functionality like this is either so broken, or so confusing, it makes me question - could the idiots that wrote code this inefficient, this lazily executed - could they actually write secure code?

Maybe they can - but every idiotic mis / broken feature I’m coming up against (and there have been a few now) erodes my confidence that any of this codebase is well written.

This problem is affecting multiple users. In fact, it’s discussed in 2018 (without resolution), in 2020 (with a bad resolution), and in 2022, we see the true attitude of NC devs - “its fine for us, so lets just warn everyone with a low end box that we cant be bothered to support them at all”, where adding a warning to the admin page if preview_max_x or preview_max_y are <4k:

I mean, freaking 4k!!! who the hell needs a “preview” at 4k?! just serve me the damn image at that size!

I need a preview of a 4K image at maybe 256 pixels ABS. MAX in the file browser. I neither need nor want a larger preview. if I want it >256px in size, I want the original. End of story.

2018: Gallery image quality is bad · Issue #444 · nextcloud/gallery · GitHub
2020: Allow loading larger preview or full-sized images in image viewer · Issue #578 · nextcloud/viewer · GitHub
2022: Uploaded photos are not shown in full size · Issue #1205 · nextcloud/viewer · GitHub
2024: When is a preview not a preview (Breaking user expectations)

TL; DR: badly thought out / sloppily executed features erode user confidence in the product. If you can’t even write a basic photo viewer, why should anyone trust your code to be internet facing and secure?

Update - setting enable-previews to false helps a bit.

This appears to force the “files” app to serve up the original, and still use the pre-generated thumnails generated by preview-generator.

UNFORTUNATELY - this does not fix the issue for the (otherwise excellent) Memories app, which seems to be unable to serve up the full res image, and goes for the largest preview instead, resulting in it being excessively blurry.

Btw - all of this would be a lot less painful if the NC server wasnt just so attrociously slow. I mean - seriously, 18 seconds to send a 3.1MB JPEG over a LAN that can pull 300Mbits over ssh? What is it doing? running every script 100 times just to make sure it got it right?

A BBC micro (Commodore 64 for the yanks) could move data faster than this.

I could print out my photos on little bits of paper, then fold them into little boats and float them down my staircase on a flood of industrial-grade molasses and it would be faster than nextcloud on this quad code 2GHz PC.

For a project that’s been going for years, frankly, it’s sh*t.

Which version of Nextcloud are you running?

Currently, one box is running 28.0.2 (stable) on an ARM64, and the other is running 28.0.3-rc2 on an x86-64.

They were both running 28.0.2 up until last night.

It may help if you switch on the verbose mode while generating the preview images?

occ preview:generate-all -vvv

NC28.0.2 and NC28.0.3-rc2

I already did. Nothing of interest logged.

Did you tried the external preview provider instead already?


One of the machines has had a disk failure, so it’s offline until I can get a replacement (raid 5). It’s also had the classic Intel atom motherboard failure, and no longer powers up properly.

I’m going to replace it with an 8GiB RockPro64 (I’m quite pleased with the one running the other NC box).

The external preview provider works, and I can see it generate the previews - but the apps behave badly;

With preview_max_{x,y} set to 4K, it “works” as expected;

  • Photos app - previews are sharp and fast, clicking on the image gives a sharp image
  • Memories app - ditto.

With preview_maxx_{x,y} set to 256, it’s not so great;

  • Photos app - previews are fast, but clicking on an image is slow (and these are only 3MiB JPEGs), like 5-10 seconds to render them.
  • Memories app - previews are fine, but viewing gives a blurry image, until you click on it, which zooms and goes “full res” quite quickly, and clicking again goes back to normal scale, but the image is no longer blurry. Closing it and re-opening it, it goes blurry (as before), so the result is not cached.

I *expected to see, from both apps:

  • Previews up to 256px wide
  • main viewer shows original image if the max preview image is too small
  • Never show a blurry image, except whilst auto-loading a sharper one

256 is too low, 1024 or 2048 would be more reasonable. If >256 is too high for you, you just need more storage at that point.

See Configuration - Memories

Memories also lets you configure the behavior when opening the viewer (you can, for example, load the full res image immediately). The admin panel has configuration on this.

Obviously your setup is broken in other ways …

Some of us (me) shoot in 64MP+ so 4K is tiny. I still use 2048 though, seems like the best balance.

You seem to be missing another fact: not everyone uses JPEG for originals (which is the only thing browsers support besides WebP). To be able to serve the preview / image fast, it needs to be pre-converted to a JPEG (which will, of course, take up storage)