Bug 433822

Reading the Baloo information works without any problems. Just tested here. However, Baloo has the lowest (last) priority. If digiKam finds a valid rating in the metadata, it will be used, even if it is a zero rating.

Maik

We won't change this behavior either, Baloo is deactivated by default and we actually wanted to remove it completely. Even if the stability has improved in the current KF5 versions, Baloo has brought us many bug reports with crashes over the years.

Maik

If you only want to use Baloo, you can switch off reading of the rating tags in the advanced metadata settings, then we will only read Baloo.

Maik

Thank you for the replies...

> ... Baloo has brought us many bug reports with crashes
> over the years ...
I don't think I was using it in the bad years. Now, from my perspective, I think "hat's off". It's an incredibly messy and challenging project.

My feeling here is that digiKam is reading/writing xattr on the filesystem, the data you can see with "getfattr -d". Baloo reads this data, digiKam can read and write this data. For this bit of the work it _seems_ the two are independent.

> ... you can switch off reading of the rating tags in the
> advanced metadata settings ...
It could be that I've written changes done within digiKam back into the embedded metadata, and digiKam is reading this info in preference to (modified) extended attributes. I will check. I am happy to carry on troubleshooting

As an initial suggestion. If people see:

    Read metadata from Baloo

there'll be an expectation that digiKam will try to read the info. Could there be an option in the advanced settings, to show xattr as a source - and list things like user.baloo.rating, user.xdg.tags etc explicitly, although by default unchecked, at the bottom of the list?

Further on perhaps, if "Read metadata from Baloo" is selected, these options could be checked

Git commit 583c39033bec33e6bcca7e475ebb9d9d91a8f2c9 by Maik Qualmann.
Committed on 02/03/2021 at 20:20.
Pushed by mqualmann into branch 'master'.

cleanup Baloo API and fix QString memory leak

M  +5    -4    core/libs/fileactionmanager/metadatahub.cpp
M  +6    -21   core/utilities/extrasupport/filesindexer/baloowrap.cpp
M  +1    -7    core/utilities/extrasupport/filesindexer/baloowrap.h

https://invent.kde.org/graphics/digikam/commit/583c39033bec33e6bcca7e475ebb9d9d91a8f2c9

Git commit cf9f68128d5f5fe87d0fec67a912ca8a39703c7a by Maik Qualmann.
Committed on 02/03/2021 at 20:46.
Pushed by mqualmann into branch 'master'.

fix sync rating value from Baloo
FIXED-IN: 7.2.0

M  +2    -1    NEWS
M  +6    -1    core/libs/database/item/scanner/itemscanner_baloo.cpp

https://invent.kde.org/graphics/digikam/commit/cf9f68128d5f5fe87d0fec67a912ca8a39703c7a

Git commit 67426dc24ab1a4c2c1b1528258fba63dbcf7bcb6 by Maik Qualmann.
Committed on 02/03/2021 at 21:11.
Pushed by mqualmann into branch 'master'.

factoring Baloo API

M  +5    -7    core/libs/fileactionmanager/metadatahub.cpp
M  +7    -10   core/utilities/extrasupport/filesindexer/baloowrap.cpp
M  +7    -9    core/utilities/extrasupport/filesindexer/baloowrap.h

https://invent.kde.org/graphics/digikam/commit/67426dc24ab1a4c2c1b1528258fba63dbcf7bcb6

> I am happy to carry on troubleshooting

Yes, my test file had had the metadata written back into them, that and the advanced settings meant that reading extended attributes would have been "at the bottom of the list"

Testing, step by step (using the "old build" of 2021-03-02)

    Configured digiKam metadata settings, leaving 'Advanced' setting
    as default, close digiKam

    Created clean test files (confirming no embedded metadata), set Tags
    and Ratings values in xattr for some of the test files

    Ran digiKam, confirm that it picked up the images.

        ... It had not picked up the xattr values

        ... but that can be explained by the default 'Advanced' settings

    Reconfigured digiKam settings, clearing the selections to
    read/write embedded metadata under 'Advanced' for tags and ratings

    Changed xattr Tags/Ratings (via Dolphin), reran digiKam.

        ... Changes were not seen. Ohh... :-(

    Updated timestamps on all test files, with "touch *" ...

        ... Changes became visible after an F5 refresh. Ahhh :-)

    Changed tags and ratings within digiKam (for one test file)

        ... extended attributes also changed (Good)

So that's reasonably clear. Need to be careful about embedded metadata when testing, it's not obvious at what point and in what situations it gets written to the file. Need to know about the "Advanced' settings and also realise that changing extended attributes is "invisible" to digiKam; it checks when it sees the timestamp changes.

Equivalent run with today's build (2021-03-03) to follow....

Repeating for today's, 2021-03-03, build

    Configured digiKam metadata settings, leaving 'Advanced' settings
    as default, close digiKam. 

    Created clean, new test files (without embedded metadata), set Tags
    and Ratings values in xattr for some of the files as before...

    Ran digiKam, confirm that it picked up the images, and ...

        ... It *has* picked up the xattr values.

That's good stuff :-)

    Changed the Tags and Ratings values with Dolphin, checked in
    digiKam 

        ... Changes were not seen. Ohh... :-(

    Update the timestamps ...

        ... Changes became visible after an F5 refresh. Ahhh :-)

So digiKam should ideally(!) read the extended attributes while it is reading the modification time in order to pick up changes. I'll submit this as a 'wishlist' change

I've not looked to see what happens when an image file has both embedded metadata and external attributes. That's probably something to come back to...

> So digiKam should ideally(!) read the extended attributes while it is
> reading the modification time in order to pick up changes. I'll submit this
> as a 'wishlist' change

No, digiKam will definitely not read the Baloo information when the modification date is read. digiKam also doesn't read metadata every time. You will not be able to avoid re-reading the metadata. And F5 does not read in the metadata again, it creates new thumbnails and finds new and changed elements based on the modification date.

Maik

Sorry, I was trying to be very careful (and making sure I was getting repeatable results). It's possible though that my wording was amiss.

The 2021-03-03 build works far better, thank you for the quick patches

The 'gotcha' with extended attributes is that if you change them (in Dolphin/Gwenview/etc) that does not change the modification time of the file. The file itself is not changed.

In order to follow changes in the extended attributes, you _also_ need to change the modification time and do a refresh. Does that make sense? Or am I missing something?

I also had a look to see if I could see any dependencies on baloo as a service. If I run the tests with the baloo services disabled and the database deleted, it seems not to make a difference. DigiKam is just reading the extended attributes...