"Writing metadata to files..." never finishes

Bug #894553 reported by Dmitry Kann
104
This bug affects 23 people
Affects Status Importance Assigned to Milestone
shotwell (Fedora)
New
Undecided
Unassigned
shotwell (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

After last update Shotwell always starts to write metadata to files upon startup, progress shows 50%, 75%, 88%, then slows down and stalls at 99%.

top doesn't show any considerable CPU usage, HDD doesn't seem to be used either. Console doesn't show anything.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: shotwell 0.11.6-0ubuntu0.1 [modified: usr/share/glib-2.0/schemas/gschemas.compiled]
ProcVersionSignature: Ubuntu 3.0.0-14.23-generic-pae 3.0.9
Uname: Linux 3.0.0-14-generic-pae i686
NonfreeKernelModules: fglrx
ApportVersion: 1.23-0ubuntu4
Architecture: i386
Date: Thu Nov 24 22:20:52 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta i386 (20110921.2)
SourcePackage: shotwell
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Dmitry Kann (yktooo) wrote :
Revision history for this message
Dmitry Kann (yktooo) wrote :
Revision history for this message
Adam Dingle (adam-yorba) wrote :

Thanks for the bug report. Could you generate a log file and attach it to this bug? To do that, run Shotwell from the command line like this:

$ SHOTWELL_LOG=1 shotwell

After the metadata writing hangs, exit Shotwell. Then find the file ~/.cache/shotwell/shotwell.log and attach it here. Thanks!

Revision history for this message
Dmitry Kann (yktooo) wrote :

Here you go. It endlessly processes the same file. The file itself is OK (I checked it).

Revision history for this message
Adam Dingle (adam-yorba) wrote :

Thanks for the bug report and log file. This has also been reported upstream at http://redmine.yorba.org/issues/4297 .

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in shotwell (Ubuntu):
status: New → Confirmed
Revision history for this message
Dmitry Kann (yktooo) wrote :

I haven't had this problem for quite a while, but after I added a bulk of photos—it's here again. Very annoying, it causes the PC to endlessly update the files.

Can this be addressed somehow?

Revision history for this message
Adam Dingle (adam-yorba) wrote :

We're not able to reproduce this so it may be challenging to fix, but we can look at the log file above and maybe that will give us some clues. I've just targeted the upstream bug for the next release of Shotwell (0.13). We'll see what we can do.

Revision history for this message
Dmitry Kann (yktooo) wrote :

Thanks Adam, I also attach the most recent log, maybe it might help. By the way, looks like "*_modified" files cause this behaviour. In the log I see a lot of "timer restarted" events, like this:

L 30918 2012-04-08 15:53:22 [DBG] Photo.vala:3144: pipeline being run against [11713] /home/dk/Pictures/Photos/2011/08/02/dsc05782.jpg (/home/dk/Pictures/Photos/2011/08/02/dsc05782_modified.jpg), timer restarted.

Can it be caused by file system notification on file change?

Revision history for this message
Adam Dingle (adam-yorba) wrote :

Dmitry,

if this problem currently occurs every time you start Shotwell, could you do the following?

1. Generate a log file following the steps in comment #3 above.
2. Look at the log file to see which photo(s) are being processed endlessly.
3. Send email to <email address hidden> and attach your Shotwell database (~/.shotwell/data/photo.db), the log file (~/.cache/shotwell/shotwell.log) and the photo file(s) which are being processed over and over.

That should help us debug this. Thanks!

Revision history for this message
Adam Dingle (adam-yorba) wrote :

Dmitry,

good news: I figured out how to reproduce this, so I don't need anything more from you. I posted a list of steps to the upstream ticket (http://redmine.yorba.org/issues/4297). We should be able to fix this for 0.13.

Revision history for this message
Ulf Rehmann (rehmann) wrote :

What is the state of this bug?

With a collection of more than 12000 photos, I am right now suffering from this bug as well quite a bit.

If no fix is available yet, is there any workaround?

Thanks for any hint.

Revision history for this message
Adam Dingle (adam-yorba) wrote :

This was fixed 5 months ago in trunk (see the upstream ticket at http://redmine.yorba.org/issues/4297) and so the fix will be present in the upcoming 0.13 release. If you'd like the fix today, you can either install Shotwell from the Yorba daily PPA (https://launchpad.net/~yorba/+archive/daily-builds) or upgrade to the Ubuntu Quantal pre-release, which includes Shotwell 0.12.90 which has this fix.

Changed in shotwell (Ubuntu):
status: Confirmed → Fix Committed
Revision history for this message
Ulf Rehmann (rehmann) wrote :

Thanks very much, that's great!

I installed on Ubuntu 12.04 after compiling from Quantal's 0.12.90
source tarball.

Works well and seems to prevent me from falling back to digikam...

Revision history for this message
Øyvind Stegard (oyvindstegard) wrote :

I see this bug in Ubuntu 12.10 using Shotwell 0.13.1. Isn't the bug supposed to be fixed in this version ?

Revision history for this message
tornadof3 (p-m-reid) wrote :

I also have this same bug on Ubuntu 12.10 Shotwell 0.13.0

Revision history for this message
Roberto E Ferrer Pirela (refp16) wrote :

Hello,

Using Ubuntu 12.10, shotwell 0.13.0.
Same problem here with metadata writing. Stuck at 99%.
Sending log file and database to <email address hidden>.

Thanks.

Revision history for this message
Marco Martini (marco-martini1971) wrote :

Hello i'have the same problem on ubuntu 12.10 64 bit and shotwell from repository (0.13.1)
only work around disable writing labels in files option.

Revision history for this message
Jim Nelson (yorba-jim) wrote :

This is known to still be a problem in Shotwell. We hope to look at this for the 0.14 time frame. The upstream ticket for this work is at http://redmine.yorba.org/issues/4297

Changed in shotwell (Ubuntu):
status: Fix Committed → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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