[Shotwell] Call for testing!

[Adam Dingle]

Martin Olsson wrote:
> I kicked its tires some more today.
>   
Great - this is exactly the kind of testing we need.
> * If you run "./configure --help" it says that "--release" is the default
> but this is not the case (you set BUILD_RELEASE=1 in the makefile and then
> after that you include configure.mk which might override, but in the end
> you have hardcoded -g for VALAFLAGS). Debug info is nice but valac also
> generates #line directives in "-g" mode which makes gdb jump back and
> forth between .c and .vala files so I prefer to configure in release mode
> without -g and then just build Shotwell explicitly with:
>
>   CFLAGS="-g3 -O0" make -j4
>
> This is why I think it would be nice if --release suppressed the -g param.
>   
It sounds like you'd be happier if --release passed -g only to gcc, not 
to valac.  We could consider making that change. I've filed a ticket ( 
http://trac.yorba.org/ticket/1169 ).
> * Suppose a user repeatedly runs "Import From Folder" on his home folder
> hoping that the duplicate detector will ensure his photo collection
> is kept tidy anyway. Today, after a while he will notice that there a
> lot of duplicates in his photo collection anyway and they will be called
> stuff like "thumb000000000000038d.jpg" etc. What has happened is that
> Shotwell has been scanning "~/.shotwell/thumbs" and imported stuff from
> there. I suggest this particular dir should be suppressed from scanning.
>   
That's a reasonable idea.  We might also want to suppress all 
directories whose names begin with "." since they might contain 
thumbnails or temporary files.  I've filed a ticket: 
http://trac.yorba.org/ticket/1164 .  Will probably fix for 0.5.
> * When "Import From Folder" runs out of disk space, then Shotwell will
> sometimes SIGABRT's with this error:
>
>   ** ERROR **: LibraryFiles.vala:34: Unable to create photo library directory BLAH
>
> I'd ask you to re-consider this one and change the error() to something
> a bit more graceful since out of disk is not unreasonable for first time
> users doing big imports into Shotwell (especially if you have
> "Copy to ~/Pictures" on).
>   
Right: we should fix this.  Ticketed at 
http://trac.yorba.org/ticket/1165 .  We might even fix this for 0.4; 
still undecided.
> * When I select "Import from folder" on my homedir (which is 13GB with
> tons of small files and tons of folders) the "Import From Folder" dialog
> remains open for minutes while my HDD works intensely (I suppose it's
> making a list of all the photos to import). It would be nicer if that
> dialog disappeared before the HDD scanning starts (possible you're calling
> hide early enough but maybe the GTK mainloop is not given time to process
> that hide message?).
>   
Ticketed: http://trac.yorba.org/ticket/1166
> * It would be nice with a progress bar for long running imports. For large
> imports Shotwell currently shows all black in the "Importing..." page and
> appears to do nothing for several minutes before the images starts to swizzle by.
>   
Ticketed: http://trac.yorba.org/ticket/1167
> * Just for kicks I ran "Import From Folder" on my ~/src folder which has
> the mozilla tree, the kernel code etc. I was thinking this would be nice
> stress test to see if Shotwell ignores unexpected file types and still finds
> the images. First I noticed that Shotwell seems to spend time processing
> non-images, look at the stack snippet below for example. Why call
> batch_import_import_file for a non-image file at all?
>
> Note especially what happens when the dupe checker finds a bunch of 4GB .mvk files.
> To quote the Shotwell code "// if no EXIF data, then do full MD5 match" :-)
> For example, put 10-20 4GB .mvk files into a folder and try to let Shotwell do
> "Import From Folder" on it, while you fire up "iotop" next to it. Lot's of bytes
> flying both on and off the disk it seems.
>   
True.  Ticketed at http://trac.yorba.org/ticket/1168 .  We should be 
able to fix this for 0.4.
>
> * Finally, after I let it chew a while on importing the full mozilla source tree I got this SIGABRT crash:
>
> **
> ERROR:Photo.vala:1116:transformable_photo_load_raw_pixbuf: assertion failed: (dimensions_approx_equals (&scaled_image, (_tmp5_ = (dimensions_for_pixbuf (pixbuf, &_tmp4_), _tmp4_), &_tmp5_), TRANSFORMABLE_PHOTO_SCALING_FUDGE))
>   
You found a crash - congratulations.  :)  Ticketed at 
http://trac.yorba.org/ticket/1163 .  We'll fix for 0.4.

Thanks again for all your tire-kicking :)

adam