Stable content identifiers will cause some data loss for existing users of two existing GNOME apps: starred songs in Music, all albums and starred pictures in Photos. There are ways we can mitigate that before GNOME 42 is released, so please comment if this will affect you so we know where to direct our efforts.
The performance improvements are impressive, initial numbers show indexer memory usage cut by half, and usual startup time almost 3x faster. It’s soon time for GNOME 42.alpha and we need wide testing of these big Tracker Miner FS changes. I will add some info in a moment about how you can help.
Any issues that you spot, please report as issues or in IRC, making it clear what version you’re using. I’m not sure exactly what sort of bugs there might be in this new code - presumably none, but you never know Crashes, very high CPU/memory use, and files missing in search results are all possible issues.
The stable URNs are based on filesystem-specific data (specifically G_FILE_ATTRIBUTE_ID_FILE). If you use a filesystem more exotic than ext4 then your testing could be very helpful to ensure our assumptions about filesystem IDs are correct. A simple test could be:
Install unstable Tracker as above
Wait for reindex to complete
Run tracker3 info on one file that should be indexed, get the content ID which will be shown as nie:interpretedAs
Reset the index - tracker3 reset --filesystem
Wait for reindex to complete
Run tracker3 info on the same file, and see if the ID is the same.
Move the file to a new location, and see if the ID is the same.
Crashes, very high CPU/memory use, and files missing in search results are all possible issues.