It was a simple patch. If you pull from trunk, this should be fixed. However, I'm still concerned about the problem of reimporting a large number of files. That ticket is here: http://trac.yorba.org/ticket/2564
-- Jim On Wed, Sep 15, 2010 at 9:52 AM, Jim Nelson <[email protected]> wrote: > 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
