Tracker errors in the log after update

elusian

Hello
since the update to gnome 3.38 at every startup I have about 30 min where tracker-miner-fs-3 and tracker-extract-3 (mainly the latter) take a lot of CPU.
Looking inside journalctl shows that tracker-miner-fs-3 throws a lot of "SQLite error: database disk image is malformed" saying "(errno: No such file or directory)" or "(errno: Bad file descriptor)" or "(errno: Resource temporarily unavailable)", while tracker-extract-3 complains about being unable to extract many files in my HDD.
I suspect this may be related to the upgrade to tracker3, because my log from before the update shows nothing like this.
I am very much unfamiliar with tracker, so I'm not sure how to solve this or even if it is expected from version 3.
Does anyone know how it can be avoided?

Thanks in advance!

be-gt

Hi, I am also getting these kind of errors, very many of "SQLite error...(errno: No such file or directory)". And if/when the cpu seems to calm down the message is "SQLite... (errno: Success)".

I think that something is wrong but I don't seem to have the reset or other fix/trouble shoot commands that I find when duckduckgoing for this issue. Such as tracker3 reset -s etc

Anyone have any ideas?
Thanks

elusian

Yes, I too have noticed that many commands found when looking for tracker3 troubleshooting instructions are missing in Solus.
Another example is tracker3 status, which is supposed to print some information about what went wrong with tracker-extract-3. tracker3 help status even says that it should work...

elusian

I believe that tracker3 is searching for subcommands in /usr/lib64/tracker/tracker3, while some of them (such as status or reset) are in /usr/lib64/tracker-miners/tracker3 as they come in the tracker-miners package.
I will open a bug report for this.

Edit: Here it is https://dev.getsol.us/T9574

elusian

A small update:

The bug report about the missing tracker3 subcommands was closed due to it being an upstream issue. I disagree on this, but I can live with the workaround. The workaround is linking the subcommands from the /usr/lib64/tracker-miners/tracker3 folder to /usr/lib64/tracker/tracker3, which as far as I can tell solves the issue. Now I can run tracker3 reset -s and this solves the SQLite errors from tracker-miner-fs-3

However, tracker-extract-3 was apparently the main culprit for the CPU usage, and the two issues seem to be unrelated. From the syslog, tracker-extract-3 seems to choke mostly on EPUBs and flac files.

Also after a shutdown tracker-miner-fs-3 shows the same errors as before (less of them, thankfully), so there is something weirder than just a corrupted database.

I hope at least that the subcommands workaround is useful to others.

hunzel

elusian
I'm sorry to ask this, but how do I link those subcommands. I have never done this and google didn't bring something up when I searched for this.
Thank you in advance!
EDIT: I now understood, that symlinks were meant. I did know what to do about those :-D Thanks! this got rid about a lot of error messages in the journalctl

elusian

hunzel
Yes, I meant symlinking the files from one folder to the other. Sorry for not answering sooner and glad that you solved the issue.