We recently introduced in trunk a new feature for Shotwell: during the
startup scan, if it detects a change to the file, it's reimported (on the
assumption that it was edited or manipulated by an external program).  This
is a feature request we've had for some time.  The ticket for it is here:
http://trac.yorba.org/ticket/2476

Note that reimporting also means regenerating thumbnails, as they need to
reflect the content of the image file.

First, Shotwell should never take this long to start, and should never hang
the UI.  I added this change some time back but didn't get a chance to
performance test it, as we've been busy dealing with getting 0.7.1 and 0.7.2
out the door (among other fire drills).

I suspect what's happening is that Unison is causing your entire library to
appear changed to Shotwell, which then dutifully schedules all of them to be
reimported.  This is obviously undesirable.

If Unison changes merely the file timestamp (i.e. it touched the file), this
will trigger a reimport.  I thought I'd taken this possibility into account;
looking at the code, I missed this.  My bad.

I've ticketed this here: http://trac.yorba.org/ticket/2563

I'll try and get to this soon.

-- Jim

On Wed, Sep 15, 2010 at 4:18 AM, Peter DO Smith <[email protected]> wrote:

> My installation of Shotwell is suffering from slow start up again, but
> under
> very specific circumstances.
> It took 34 minutes to start up. During this time Shotwell was greyed out
> and
> unresponsive.
> CPU usage varied from 40% to 99%
>
> I downloaded and compiled the latest version from trunk yesterday morning.
> I maintain two identical installations of my photo library in Ubuntu Linux
> (10.04), one at Home and one in my Office.
> The Shotwell data folder is kept in the Pictures folder (to make backup
> simpler) and I invoke Shotwell as follows
> shotwell -d /home/peter/Pictures/shotwell
>
> My Home installation is my primary installation where I load photos.
> Then I use Unison to synchronise my Pictures folder to a USB drive.
> The Pictures folder is then restored from the USB drive to my Office
> machine, once again using Unison.
>
> This strategy has worked well until now.
> Since yesterday, when I start up Shotwell on my Office machine after
> restoring from my USB drive, I find that Shotwell is greyed out and
> unresponsive for more than 30 minutes.
> If I then close down Shotwell and restart it starts up quickly, as it did
> before.
>
> I used Unison to see if the folders had changed. This showed me that
> Shotwell had rebuilt 7904 thumbnails (both 128 and 360 bit) but that the
> primary photos were still identical. I have 9668 photos in my library. Both
> sets of folders are identical in every other respect, except, as expected,
> the database had been updated
> As far as I can tell Unison does does an excellent job maintaining
> identical, synchronised folders.
>
> Why would Shotwell rebuild the thumbnails? (many but not all)
> Could the rebuild process not run in a separate thread at lower priority to
> avoid this extended unresponsive period?
>
> Thanks for including the No Events folder. That is a real life saver when I
> am scanning film.
>
> Peter
> _______________________________________________
> Shotwell mailing list
> [email protected]
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
_______________________________________________
Shotwell mailing list
[email protected]
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Reply via email to