GNOME Bugzilla – Bug 635447
Find all Untagged causes crash
Last modified: 2018-07-01 08:53:01 UTC
Created attachment 174973 [details] output using f-spot --debug f-spot reports 30210 images in collection. Over the last few weeks I have been using "Find untagged photos" extensively. I started with around 2500 untagged images and worked on batches at a time. Recently I got down to the last 80 or so untagged photos and f-spot crashed. Now whenever I select "Find untagged photos" f-spot crashes. debug attached.
This can also be reproduced on my database by starting f-spot, clicking on the First Thumbnail to highlight it, then pressing the End key. Or scrolling down to the end of the thumbnails, or basically doing anything that causes an attempt to retrieve the oldest images. By experimenting with "Set Date Range" and putting in some extreme ranges I can get some extra details. e.g. Entering the date range 01/01/1000 to 12/31/2525 is fine. No crashes. I can Select All and Find Untagged with no crashes. However the statistics are interesting. On the bottom of the screen f-spot tells me that I've selected 30092 out of 30130 photos. A disparity of 38. Do I have 38 rogue photos somewhere that are messing up my database? By going even further back in time I can get a crash by giving a start date of 01/01/0001 (01/01/0500 is fine!). Further contradictory observations. By scrolling down through my thumbnails (entire collection) I get to about 1965 and usually about there I get a crash. I haven't worked out yet exactly where (I try and creep up on it). My guess is that this has the same case as bug #635465. I also think there's probably some corruption in my database and I may need some sql help to find it and fix it.
Reproducible every time on my system by giving date range of 1/1/0001 to 1/1/0001. Note that this is precise; 1/1/0002 is OK. As is 1/2/0001 to 1/2/0001. Browsing to oldest thumbnail also causes it consistently. As noted earlier, selecting range 1/2/0001 to 1/1/2050 is ok but f-spot reports disparity of 38 uncounted photos. Perhaps I have 38 photos somehow associated with 1/1/0001?
I surprise myself at times. I'd forgotten that I invoke f-spot via a wrapper script that takes a backup of the database before each invocation and stores them beautifully arranged by date in a dedicated backup directory. By selectively overwriting the 'live' photos.db from previous f-spot runs I can find the last good backup that allows me to go to the end of the collection without a crash. This co-incides with the time I attempted to import an image that I'd rotated in gthumb pre-import. Sure enough, by importing a single gthumb rotated image, something happens to the date (1/1/0001) and things are never quite the same again. Whatever is causing the problem happens in #635465.
f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010. Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.