Hello everyone,
I attempt to use Photos as the default Image viewers and notice the long time to load all pictures (over 10 thousands). From my understanding, Photos relied on tracker3 to index images. After submitting a ticket last month with debugged log, it seems the root cause is tracker-extract-3.
The annoying part is when opening Photos, the process started over again without preserving the already loaded pictures with suggests an problem with tracker3.
Hi Luya,
I’m sorry to bring you back to square one, but that does not make sense. Here’s the role that each involved process assumes:
The key concept here is that tracker-extract-3 is a background process that is allowed (even expected) to fail/crash (say, corrupted files, bugs in the libraries used to extract metadata, …), and it failing has no direct consequence on gnome-photos or other applications since they don’t talk directly. It is however guaranteed that metadata extraction is attempted on all the relevant files, also after failures and crashes.
In the backtrace you provided in that issue, there’s indeed a tracker-extract-3 coredump, by the looks of it happened somewhere inside the gstreamer-libav plugin extracting metadata from a video file. This does just result in metadata for that file missing in tracker-miner-fs-3 database, which is irrelevant to gnome-photos. It might be interesting to forward this backtrace to the gstreamer-libav issue tracker, be it either a bug or a corrupted file it should ideally not crash.
In order to move your issue forward, you should provide a backtrace of the gnome-photos crash in that issue, as that is what can be addressed there. We’ll later see if Tracker is actually involved :).
Cheers,
Carlos
Hi Carlos,
Thank you for explaining about the functionalities of tracker-extract-3 and gnome-photos. Now with all clarifications, here is some questions:
Unfortunately, the debugging tools (gdb) provided nothing useful when the silent crash occurred. They also failed to show why gnome-photos slowly gathered photos. Which tool helps to effective show a bracktrace of gnome-photos and what is the effective approach?
Use coredumpctl gdb to get the backtrace.
Thank you. I opened gnome-photos in order to reproduce the issue at this time of writing. It is currently gathering photos (over thousand) at slow pace. I included a screencast showing the issue (kept as internal note because of clients content). The ideal is for GNOME Photos keeping loading other remaining pictures rather than temporarily stop because other users will think the application has a problem.
AFAICS, this has turned into a “why gnome-photos is slow with large collections”, if there are no crashes. Perhaps that gnome-photos gitlab issue should be reworded to remove mentions of a crash :).
Tracker does all the preemptive gathering that there is here. After your files are indexed, applications like gnome-photos can efficiently perform detailed queries around those files and their metadata (e.g. all photos, photos with landscape orientation, photos above a resolution, photos taken in a time range, photos in an album, …) without having to locate/parse/index all these files themselves.
But even with that part of the work done, gnome-photos still has a number of complex and expensive things to do:
On top of that, gnome-photos still uses GTK3, using widgets whose performance doesn’t scale properly with large data models. Doing some performance analysis is required to definitely pinpoint the parts that are expensive (and sysprof is the tool that does help here), but my hunch would be that most of the time spent by gnome-photos on large collections is around those areas.
You can get a rough idea of the baseline time taken by Tracker queries running the following command/query:
time tracker3 sparql -b org.freedesktop.Tracker3.Miner.Files -q 'select * { ?u a nmm:Photo }' >/dev/null
This CLI command times a Tracker query for all indexed photos (sending the output to /dev/null). Of course gnome-photos queries to Tracker are more complex than that, it is not 100% impossible to write queries that become a bottleneck on large datasets, but it’s unlikely to be what is happening here.
Cheers,
Carlos
Noted. I run only sysprof at the time of writing. I notice you have seen the log on the gitlab ticket.
http://tracker.api.gnome.org/ontology/v3/nmm#Photo = 113639
You should not run gdb and sysprof on the same application at the same time. I would expect there to be interference between both (since a process can only be ptrace()d by one other process at a time). It’s likely to be the cause for sysprof not quite working.
Ok, so it took a total ~1.3s to ask tracker-miner-fs-3 via D-Bus for all your photos, from first to last. This is a bit unfair, since gnome-photos queries more often in smaller chunks, and also does more complex queries, but it gives you a ballpark idea.
Out of curiosity, how many photos do you have? tracker3 status -a | grep Photo should tell.
Using a more powerful desktop hardware i.e. AMD Ryzen 9 5900X, the result
time tracker3 sparql -b org.freedesktop.Tracker3.Miner.Files -q 'select * { ?u a nmm:Photo }' >/dev/null
real 0m0.124s
user 0m0.013s
sys 0m0.011s
The number of pictures are
tracker3 status -a | grep Photo
http://tracker.api.gnome.org/ontology/v3/nmm#Photo = 24201
I include a screenshot the recorded sysprog log below:
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
