Optimizing keyword updates during writeback

[lnh]

I'm going to be doing some substantial updates to the hierarchical keywords associated with my files. The database isn't huge yet, so now is the time to have better organization. My question is whether there is a preferred way to organize the updates. For example, all the changes could be made without any writeback, and then go to each folder in the Media & Folders section and writeback a smallish number (~50 to 100) of files and wait for them to finish before doing another batch of files. Alternatively, I could look at Categories and the @Keywords and proceed in a similar way working through a category at a time. Does it make any difference how to approach this type of large scale update?

[Mario]

How long does it take on your system to write back a few keywords to 100 files?
This is usually not a big thing, especially when you can let IMatch do it alone, without trying to work.

I've made a quick check on my old system. To write back a mix of existing and about 10 new keywords per file for a set of 116 files (80 JPG, 36 RAW with XMP sidecar files) takes about 40 seconds, start to finish. Files on a normal disk, nothing in the file cache. 10 seconds less on the second write-back (adding another keyword to all 116 files).

[lnh]

Right now the db is on a local SSD, but the files themselves are on a 1Gb connected consumer grade NAS. Haven't timed it, but last time I tried something like this it took quite a while (much more than 40sec / 100 files). Maybe the approach is to move the files to a local disk for this (hopefully) one time medium mega change and then move them back to the NAS. Lots of white screen (non-responding) behavior, but I knew it was still working based on looking at task mgr for IMatch, Exiftool and network traffic. Is 100 file batches a good number of files to crunch at one time?

[Mario]

If you experience ghosting, it's usually not caused by the write-back (unless you don' write-back in the background). I would like to see a log file in this case. A NAS may be 100 times slower to respond as a normal hard disk. The affordable NAS boxes where not designed for this kind of usage.

[lnh]

I have not been writing back in the background to date, so I expect the ghosting. I've heard Windows doesn't provide programmers with very good mechanisms to report that an app is still working. Sounds like maybe I should just move the files to a local disk and use the NAS as only a backup.

[Mario]

Actually the write-back dialog is supposed to keep the IMatch UI "responsive" (processing events once in a while) so Windows does not think that IMatch is not responsive and ghosts it (or shows the dreaded "This application is not responding" message.

Problem is, when IMatch is blocked in a Windows system call (e.g. a file system routine) and it is temporarily stalled, it cannot keep everything going. And this is much more likely when a NAS is involved, because Windows may be blocked itself while accessing SAMBA on the NAS over the network. I've never seen this with a proper Windows server, but on NAS drives this happens. And ExifTool shovels a lot of data over the network when it writes back to files...