shotwell hangs with high cpu usage when dir contains many image

Hi,

First of all, thanks for this great software.

I've been trying to get rid of many _shotwell.jpg / _shotwell_1.jpg / _shotwell_2.jpg files today, without success so far.

The issue I'd like to raise is that when closing Shotwell, either from the menu or with the usual close button, the application doesn't fully stop right away and keeps running in the background, taking a significant part of the system resources (it looks like a full CPU core at 100% out of 4).

This is a really unusual behavior among desktop apps, it can decrease the battery life drastically on a laptop if the user doesn't notice, and there is no message informing the user or offering a way to control this when closing the app.

Launching Shotwell with export SHOTWELL_LOG=1 shows in the logs that it was in fact still creating new thumbnails for the recently modified pictures (the ones ending in _shotwell.jpg that it has recreated after my deletion attempt) and it finally stopped after a bit more than an hour.

From a user point of view, this is really disturbing. Would it be possible to:
1/ properly stop all long-running background actions (such as thumbnail creation) as soon as the app has been closed by the user?
2/ and maybe offer an option in the settings for users that like the current beavhior?

Personally, if I want to keep things running, I simply keep an app open but minimized. But as soon as I close an app, I expect it to stop taking system resources (and certainly not to keep using 25% of total CPU resources for 1h+ long).

I don't know if this is a design decision or if I've hit a bug, so let me know if you would need any other input. Btw, I've seen this using the master branch, compiled on commit: b5dd17ea16b1a44933fb65378dc5a30971dcec5a

Thanks a lot,
Jérôme

Created attachment 370124
Extract of shotwell.log showing a small subset of all the thumbnail creations

Did you move your library to a different place? This sounds like bug 771613

Either way, the Cache definitely should not be running when closing the window. That's a bug.

Thanks Jens. I can't tell for sure as I've moved my photo set onto different disks and then laptops, but I thought I had kept the same base directory.

Looking at bug 771613, I may be hit by that one indeed. I'll try to see if I can clean my database manually as suggested there.

With a bit of delay: I can confirm that the trigger of the issue was indeed the same bug 771613, as you had guessed.

I had changed my username when changing laptops and looking at the database, the older filepath entries in BackingPhotoTable were still pointing to the older location in /home/old_user and not in /home/new_user. Creating a symlink did the trick for me to make the filepath correct, as a quick workaround. Maybe the filepath should be relative instead of absolute for RAW + JPG pairs?

Anyway, launching Shotwell right after the symlink creation still took quite a lot of resources the very first time, and closing the window didn't stop all the background activities once again, which is the main topic of this bug. I've let it finish and I've taken the logs, that I'm attaching in case they contain something useful.

Now, I'm back with a stable and efficient Shotwell, that's a relief. I'll still need to fix the filepath in the database at some point though.

Created attachment 370424
shotwell.log taken on first launch right after the symlink fix

Logs showing the resource-heavy background activities that have happened only on first launch after the symlink fix, then everything is back on track.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/shotwell/-/issues/4918.