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

ℹ️ Support
,
1

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: https://github.com/nextcloud/viewer/issues/1205
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?

2

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.

3

Which version of Nextcloud are you running?

4

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.

5

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

occ preview:generate-all -vvv

6

NC28.0.2 and NC28.0.3-rc2

7

I already did. Nothing of interest logged.

8

Did you tried the external preview provider instead already?

9

Yes.

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
10

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.

image
image904×311 13.4 KB

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)

1 Like
11

4k is still not a “preview” in my book. 64Mpix is not THAT much higher res either (about 10x)

A preview is meant to be a thumbnail for quick browsing.

I’m not “missing” that not everyone uses JPEG (which is FAR from the only thing browsers support btw.)

I see the need for thumbnails, and can see the benefit in previews at a variety of sizes - the problem I was having at the time was the bad behaviour of NC when the preview size was set quite low - particularly by the photo viewer app.

I’ll note that the viewer seems improved in NC30. Or maybe something else isn’t broken now, who knows. It’s been a while.

12

I stumbled on this discussion when trying to figure out ways to have only small previews (64x64 and 256x256). I have same issue as the original person starting the thread: The previews takes huge amount of space. And when accessing some old folders, the system just dies on it generating the previews.
Most importantly, I DONT NEED 1300x1900 “PREVIEWS”, just show me the darn 2000x3000 original, just have browser to downscale it!

From this thread I got one idea to experiment: Set previews of at nextcloud app and have preview generator to generate the small ones.

I was thinking about experimenting with: Nightly cronjob which will remove any preview file with size more than 200Kib. (find ./preview -type f -size +200k | xargs rm). It seems like if nextcloud thinks there is a preview (it has been generated and has entry in database), but can’t find the preview file, the original will be displayed instead.
My solution has the upside of saving filespace, while still keeping the not so big previews (some images pack very well).

But as with the original poster, I totally agree: This behaviour of sending a “preview” to user when one clicks the image on files app, it’s just BRAINDEAD and waste of resources.

Last but not least: The previous comment prior this one mentions things better in NC30. I’m on NC29. Maybe I upgrade and have a go with NC30 to see if the stupid behaviuour is gone.

1 Like
13

It is encouraging to see that there are still people out there who can identify issues and articulate them in a clear and concise manner. Without individuals like you, developers would be hard-pressed to find the motivation to complete their tasks effectively. I particularly appreciate the use of words like “baindead” in all caps, which effectively convey the urgency and necessity of the situation. :stuck_out_tongue_winking_eye:

1 Like
14

Hi bb77

Yes, caps are rude and I generally avoid them. Apologies for letting my current frustration of the situation to shine trough.

Where/How can I submit an enhancement request?
I’d love to have following functionality:

  • A boolean setting, when enable it would show the original file if it’s larger than ‘preview_max_x’ x ‘preview_max_y’

Why?
Currently there already are those ‘preview_max_x’ and ‘preview_max_y’ settings. If I set the values to low (say 256 each), that’s the max resolution any image will be shown to me. Ie. I click on image file which is originally 3000x4000, I’m shown scaled down preview fitting into 256x256.
I’d be happy to see those scaled down images / previews in the file listing, but when clicking the image, original would be shown.

Just to give some perspective to this issue:
I have 1334 preview files with resolution of 3000x4000, consuming 2.45GiB. Next biggest chunk is preview files of 3072x4096, consuming 1.47GiB. That’s just nuts.

Now,
getting back to the original issue. Earlier spyro wrote:

Update - setting enable-previews to false helps a bin. This appears to force the “files” app to serve up the original, and still use the pre-generated thumnails generated by preview-generator.

I tried this with nc 30.0.2, but I was not able replicate that behaviour. When previews were set to false, previews were not generated. even having previews generated, they were not shown if previews were set to false.
I need to plan another round of testing this, with a plan.

but as it stands, currently the nigthly deletion of preview files larger than X appears to be best solution. I’m bit concerned if this “solution” will get broken by some maintenance run fixing the issues of missing preview files.

15

Memories looks kind of nice, but not what I’m looking for. I like the Files -app view and then would love to see full size image when clicking on one.

btw. the reason I’m here is similar to Spyro’s: I wanted to show some 10 year old pictures but I couldn’t because there were no existing previews from that directory (or couple of directories) and my NC basically DoSed itself out of business when I tried to locate specific images. Generating gazillion previews from externally hosted data. Most likely avoidable if the previews would have been limited to small resolution images.

1 Like
16

but as it stands, currently the nigthly deletion of preview files larger than X appears to be best solution. I’m bit concerned if this “solution” will get broken by some maintenance run fixing the issues of missing preview files.

Deleting preview files larger than 30Kb had the desired side-effect of nextcloud displaying the original images. But as I feared, this may get broken by maintenance. If one executes occ files:scan-app-data , the system becomes aware of the missing preview files and will generate them the next time that directory is accessed.

That creates a problem, at least for me. I have some 160Gib of images (and videos) stored on S3 storage. So creating previews on them causes notable amount of data transfer (i’d guestimate 100Gib). Thus that might ramp up the data-transfer bill quite soon.
I need to test if there is anything automated in nextcloud which would trigger event similar to occ files:scan-app-data. If not, then I think I can live with this…
I wonder how many days I need to wait to be sure all nextcloud’s internal cleanup items have been executed. 1 month perhaps?

17

I could be wrong, but I’d say it probably just generates a new preview on the fly in this case and then shows you that, instead of the original image, and since the max preview size of Nextcloud is 4096x4096, you wouldn’t necessary notice that, if the original image has a lower resolution than that.

Also, based on what you’ve already tested, which seems to me to be pretty much everything there is to test and tweak regarding previews, what you want just doesn’t seem to be really possible with what Nextcloud provides out of the box, and as I see it, you realistically have only three options at the moment:

  1. Disable preview generataion entierly, which will always show you the original, but obviously has the downside that you don’t get any actual thumbnails.

  2. Pregenerate previews with the Preview Generator app in all sizes, or at least in all sizes that are sensible for your usecases, which of course uses more storage, and adds to the data transfer. However the latter is one time time thing for the existing images.

  3. Use a third party app like Memories.

In addition to that, you can and probably should also open a feature request on GitHub for an option to display the original in the Nextcloud Core apps like Photos and Files, but that won’t likely be implemented tomorrow… :wink:

18

Addition:
In case I’m wrong with this, and it indeed shows you the original image in that case, you could of course write some script that regurarly deletes the larger preview files.

Of course, this trick, if it works at all, will only work if you have generated the larger previews first, because if not, I’m pretty sure it will generate them on the fly, and if you have limited the max preview size to, say, 200x200, it will only show you the 200x200 size again when you click on file, which again means it won’t really help save bandwidth costs, and you would also need the extra storage, at least temporarily.

So maybe it’s best to take a compromise and set the max size to 2048x2048, which should at least save you some space while still being large enough to view, on standard resolution office monitors.

Either way, in the end, we are back where we always are with topics like this: Nextloud is just not the optimal tool for managing media collections.

And if you do it anyway, the best way is to pre-generate all preview sizes beforehand, which then probably also means that it would be better to host it on a local server and not at a cloud provider in an S3 bucket, where every MB of storage and every KB of data transfer is going to cost you a little fortune. :wink:

That being said, I agree with you that Nextcloud should offer an option to always show the original if you have limited the preview size and click on a larger image, but that can only be done by the Nextcloud devs or a volunteer willing to make a pull request with the necessary changes/additions.

19

In the config file, you have a parameter to set the max preview size:

It’s already a longer discussion and I didn’t go through all the details, but it should do what you need, no?

20

Afaik, it will then only show the images in the defined preview_max size when opened from the Files or Photos app, unlike in Memories where you have an option to load the original image when zooming in.

And the tests made by @57rrm5ue4z do confirm this, if I understand them correctly: