https://bugs.kde.org/show_bug.cgi?id=405235
--- Comment #6 from MarcP <iwannaber...@gmail.com> --- Ok, so I experienced this problem when I lived abroad, and had a ~100ms ping, but it's no longer the case, so I tried to find ways to assess startup and scanning speed by simulating high network latencies. So I used this command to add a 100ms delay to my computer's wifi and replicate the results: # tc qdisc add dev eth0 root netem delay 100ms The good news: digikam takes as long to show the interface in a slow network as in a fast one (so, not super fast, but acceptable). However, once the interface has loaded, the initial scan for changes is still quite slow. I am just testing it, and it took me around 45 minutes to finish scanning (~100000 photos). But that's much faster than the 12 hours it took before. I also think it's remarkable that, while digikam is scanning for new pictures, the interface is responsive and I can browse albums and tags just fine (solved in bug #389652, but I have not tried if new thumbnails are generated during the initial scan, though). Overall, I would say that 3/4 of the bug has been resolved, as digikam is usable much quicker, and from the start. However, the initial scan is still too dependent on the network latency, as I guess it needs to access every single one of the pictures to check if something has changed. Couldn't that be done in bulk? Or maybe requesting the changes to the filesystem instead of checking every file individually (I'm not sure if that's possible, I'm just wondering). So, if you want to close this bug, it's fine for me, there have been big improvements since I opened it. The only issue is how long it takes to scan for a large library, specially being dependent on the network latency, but maybe that could be addressed separately. In any case, thanks for your time and effort! -- You are receiving this mail because: You are watching all bug changes.
