Bug 509161

Summary: Metadata sync reloads all image data unnecessarily (SLOW on network drives).
Product: [Applications] digikam Reporter: fotograaf <fotograaf>
Component: Metadata-EngineAssignee: Digikam Developers <digikam-bugs-null>
Status: REPORTED ---    
Severity: normal CC: caulier.gilles, metzpinguin
Priority: NOR    
Version First Reported In: 8.7.0   
Target Milestone: ---   
Platform: Mint (Ubuntu based)   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description fotograaf 2025-09-05 15:54:59 UTC 
SUMMARY
Digikam re-reads entire files when only tag information is updated.
This is very slow and unnecessary so, as all information is already available within the program.
I use Digikam to manage many raw files on a network drive and when I update tags for a few hundred files I must take a long break. 
Note: This is especially annoying when it concerns raw files. Only the XMP file is changed, the raw file is not touched. Yet all the raw files, 20MB each, are reloaded.

STEPS TO REPRODUCE
1.  Have some image files on a NAS or network drive
2.  Activate 'laze updates' (optional)
3.  Change a handful of tags, click update

OBSERVED RESULT
4. observe the network interface graphs shoot up and stay high while all changed files are reloaded.

EXPECTED RESULT
Just the changed data and do no re-read the entire image file.
Because DK knows what has just been changed, it doesn't need to reload it.
Possibly recognize that the raw file was not touched, only the XMP file was, and all information is already available and does not need reloading.

SOFTWARE/OS VERSIONS)
Linux/KDE Plasma Mint 22

ADDITIONAL INFORMATION
The reload-everything-always behaviour was present in GPS tagging, where just assigning GPS locations would reload ALL the image files. This has been fixed!  And the difference in usability is night and day.
I hope this can be fixed for tags as well.
I would really make a huge difference.
Comment 1 Maik Qualmann 2025-09-06 07:41:26 UTC 
Unfortunately, the file metadata needs to be reread. While writing tags, important file data changed, such as the file size or the unique file UUID. To calculate the file UUID, the entire file must be read. This must be updated again so that the information in the database is back in sync.
We could speed things up a bit if only writing to sidecars was enabled. In this case, only the modification date would need to be updated.

Maik
Comment 2 fotograaf 2025-09-08 10:15:49 UTC 
(In reply to Maik Qualmann from comment #1)
> Unfortunately, the file metadata needs to be reread. While writing tags,
> important file data changed, such as the file size or the unique file UUID.
> To calculate the file UUID, the entire file must be read. This must be
> updated again so that the information in the database is back in sync.
> We could speed things up a bit if only writing to sidecars was enabled. In
> this case, only the modification date would need to be updated.
> 
> Maik


I see your point.  You mean that for Jpegs you compute a UUID, like a hash or a checksum - I get that.

It would completely solve my problem if you could only fix this for sidecar files.
My problem is entirely with managing raw files, and of course these are much bigger than jpegs.  
So fixing this would improve performance on the largest files, where it makes the biggest difference!
Comment 3 caulier.gilles 2025-12-12 15:36:48 UTC 
>I see your point.  You mean that for Jpegs you compute a UUID, like a hash or a checksum - I get that.

It's a hash computed on first kb of the file, not whole file.

Gilles Caulier
Comment 4 Maik Qualmann 2025-12-12 15:57:55 UTC 
Not quite. Even UUID version V2 already read blocks at the beginning and end of the file. UUID version V3 also reads blocks in the middle of the file. It turned out that V2 wasn't unambiguous enough, for example, with TIFF files.

Nevertheless, V3 is not slower than V2. It's important to remember that even on network drives, the file is already in the disk cache, simply by reading the metadata.

Maik