search

darktable-org / darktable

darktable is an open source photography workflow application and raw developer
https://www.darktable.org
GNU General Public License v3.0
9.08k stars 1.1k forks source link

UX: editing tags attached to many images should use background job #8909

Open ralfbrown opened 3 years ago

ralfbrown commented 3 years ago

When editing the path of a tag attached to a large number of images, the dt interface goes completely unresponsive until all of the affected sidecar files have been updated. For a tag attached to many thousands of images, this can take several minutes....

The ideal solution would be to fire off a background job with progress meter for the sidecar writes, much as is done for imports and exports. The one tricky part there would be ensuring that edits don't get overwritten if the user is actively working on one of the affected images while the sidecar writes are in progress, but I think simply disallowing further tag edits until completion and pulling the current database record when the process gets around to a particular image will be good enough to avoid clobbers.

Q&D solution for 3.6 would be popping up a small window explaining that dt is busy writing N sidecars and will be useable once again when that process completes.

Additional context This came up when undoing the results of a possible bug last night. Somehow, instead of opening up path X via clicking to attach one of its subtags to the selected photos, I managed to move all of X's subtags to path X/X with no confirmation requested. At that point, dt appeared to hang and I eventually killed it (I later figured out that it was writing 12,000 sidecar files). Moving the tags back had to be done one at a time with confirmation for each, so fortunately there were only three of them.

github-actions[bot] commented 3 years ago

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

github-actions[bot] commented 1 year ago

This issue did not get any activity in the past year and thus has been closed. Please check if the newest release or master branch has it fixed. Please, create a new issue if the issue is not fixed.

github-actions[bot] commented 1 year ago

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

ralfbrown commented 5 months ago

Still on my TODO list, but I wouldn't be offended if someone else decides to take this on before I get to it in late Spring or early Summer.

jmgurney commented 3 months ago

I'll second this. I have a related issue on 4.6.1 that if you add tag a small number of files (~300), it takes multiple seconds to tag them all, and during this time, the UI is completely frozen (beach ball). There is no way it should take multiple seconds on my M1 Mac. The entire library has just over 300 images, and there are only 8 tags in total, so the DB is very small, and not a problem.

amac,ttys013,~/.config/darktable,515$ls -lh *.db
-rw-r--r--@ 1 jmg  staff   672K Mar 15 15:45 data.db
-rw-r--r--@ 1 jmg  staff   1.4M Mar 15 16:02 library.db

If the tagging routines were fixed to not be such bad performance, it's likely it doesn't need to be moved to a background task.

ralfbrown commented 3 months ago

The slow part is that the sidecar files get rewritten for each image to which a tag was added or removed. Even on a very fast drive, that can only be done for around 100-200 images per second.... It's not the routines themselves which are slow, it's the file I/O.

github-actions[bot] commented 1 month ago

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.