Collecting images from NAS with local thumbnails

Hi.

Question
Why darktable shows network activity when browsing images in Lightroom if all image thumbnails are local?

Context
Images on NAS, thumbnails in local .cache folder.
I’m collecting images that aren’t tagged, so I narrowed down the search with this set of rules:

image

where I select all images from the root folder, then exclude the first tag branch (Pessoas), then the second (Tema), and then the last branch (Local). These rules work as expected and bring only untagged images. However, when I browse thru them, they load solowly and I can see network activity.

1 Like

What is your preview setting?? 1/2 size raw maybe??

Disclaimer / background: I have all my photos on an external hard disk (traditional, spinning), not a NAS (except for backups). But I find it a bit slow sometimes to browse through photos, when the thumbnails aren’t in my main SSD and they haven’t been already generated (such as on a new installation, or if I cleared cache).

My workround is to run darktable-generate-cache and let it run until it’s finished… in my case I have 4TB of photos, so it runs overnight on a full run. You can interrupt it and run it again and it will pick up where it left off. The result of running the command is that darktable will feel a lot faster. (You only need to run the command the first time to create thumbnails, or if you need to create a bunch of thumbnails again without waiting on darktable’s UI.)

Even if all your thumbnails are local, you may have lookup requests for sidecar files like XMP or txt (if you have it enabled). Some extensions may also look up information as well. So you might need to adjust your settings a bit if this is the case.

Additionally, darktable looks up the files to see if they exist or are missing, so there’s at least a bit of activity. (Of course, you could check them out locally if you know you want to work on a set without being connected.)

2 Likes

Yes, this one.

Yes, that’s what I also have done, and, specifically, ran it with -m 7 (a bet for quality and speed).

Makes sense. I wonder if for the kind of refined lookup I illustrated in my opening post that would be the case (get tags from the xmp files)… Anyway, I would expect that the network overhead for this kind of queries would be small, but it isn’t: it maxes out my wifi connection during some seconds until the thumbnails are all loaded into the visible lightroom window. Then, if I scroll down, it starts the network activity once more until it loads them, and so on.

Well Dt seems to process the pipeline when dealing with raw files …maybe this is the issue when using raw preview and it causes the need for frequent updates to the cache preview as you edit as well…???

For clarity, I wasn’t editing at this time, I was just collecting and browsing through collected thumbnails. Some of the collected images have been edited in the past, others haven’t.
My goal in this session was only to continue the tagging of all my images, a task that will last for a while.

What I was getting at is raw previews might need to be recalculated each time you switch images….ie not a fixed cached preview

Ah, I see, that would explain this behavior.
However, there wasn’t any noticeable cpu spike, as far as I remember.

I reset the collect filter, chose another one, then applied again the filter shown above and this time the scrolling was fast, as expected.

I don’t know what to say now.

Anyway, thanks to all for your help.

Me either…

What if you go back to it and if slow again remove criteria one at a time and see if you find the culprit???

I did it :smiley:

So, I got the impression that the first time I applied a tag filter it needed some information, probably from the sidecar files. Since my collection is reasonably big (40K images), it ended up doing an expressive amount of network I/O.

Nice