shotwell hangs with high cpu usage when dir contains many image

Bug #1836019 reported by shisui
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ubuntuone-shotwell-plugin
Expired
High
shotwell (Ubuntu)
High
Unassigned

Bug Description

After close shotwell
>$ pgrep shotwell |wc -l
>4
shotwell still run backgroud.
with high cpu usage,.
Load average: 5.95 5.02 3.80

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: shotwell 0.30.2-0ubuntu2
ProcVersionSignature: Ubuntu 5.0.0-20.21-generic 5.0.8
Uname: Linux 5.0.0-20-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.10-0ubuntu27.1
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Jul 10 16:19:32 2019
InstallationDate: Installed on 2019-06-02 (37 days ago)
InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210)
SourcePackage: shotwell
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
In , Jérôme de Bretagne (jerome-de-bretagne) wrote :

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

Revision history for this message
In , Jérôme de Bretagne (jerome-de-bretagne) wrote :

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

Revision history for this message
In , Jens Georg (yg-jensge) wrote :

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

Revision history for this message
In , Jens Georg (yg-jensge) wrote :

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

Revision history for this message
In , Jérôme de Bretagne (jerome-de-bretagne) wrote :

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.

Revision history for this message
In , Jérôme de Bretagne (jerome-de-bretagne) wrote :

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.

Revision history for this message
In , Jérôme de Bretagne (jerome-de-bretagne) wrote :

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.

Revision history for this message
shisui (jawliet) wrote :
Revision history for this message
Jens Georg (yg-jensge) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks Jens for the upstream bug reference!

Changed in shotwell (Ubuntu):
importance: Undecided → High
status: New → Triaged
Revision history for this message
In , Gnome-sysadmin (gnome-sysadmin) wrote :

-- 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.

Changed in ubuntuone-shotwell-plugin:
importance: Unknown → High
status: Unknown → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.