[Shotwell] Final Call for Testing: Shotwell 0.12

[Adam Dingle]

Martin,

thanks as always for your thorough testing and helpful suggestions.  
I've created Redmine tickets for many of your points below - that 
doesn't mean we'll be able to address them all during the 0.13 
development cycle, but I'd like to get to many of these sooner or later.

On 03/25/2012 12:20 PM, Martin Olsson wrote:
> I built and tested 0bbbbd1. It looks solid. The only SEGV I saw
> was http://paste.ubuntu.com/899526/ but I couldn't repro and I'm on
> 12.04 nightly so it might not be shotwell? Anyway. here is some stuff
> I noted:
>
> *** Even if I have the youtube plugin enabled in preferences, I can't
> see youtube listed when selecting a video and clicking PUBLISH ? Not
> sure how that's supposed to work?

As you pointed out in a later email this was because you had some photos 
selected too, which can't be published to YouTube.

>
> *** If I record a _single_ video recording with a Canon Legria HF200,
> then import everything that's on the memory card into shotwell; then
> the library shows 5 copies of a stock "movie tape" icon (if I click
> them totem opens and says "unable to determine stream type"), also I
> see one video thumbnail that is showed as a photo (not that strange
> since it's a JPG) and also the actual video clip I recorded. It would
> be nice if Shotwell didn't create all these other extra thumbnails
> that cannot be played anyway. I've compressed everything on the memory
> card after shooting a single recording and uploaded in a tgz here:
> http://temp.minimum.se/shotwell_issues/straight_from_memcard_on_hdcamera_canon_legria_hf200.tgz 
>
> These kinds of AVCHD cameras (which is a standard btw, it's not just
> Canon cameras that use this) have a pretty extensive directory tree of
> video files, video thumbnails and other metadata and I think it's fair
> to say that the typical user might not even be able to determine which
> of these files are the actual movies and which ones a metadata. So I
> think it's pretty important that Shotwell learns about these directory
> structures so that A) it doesn't create those stock movie tape
> thumbnail entries that can't be clicked anyway, and so that B) it can
> couple the video thumbnail to the actual video like the RAW+JPG thing
> (or maybe just ignore the video thumbnails if shotwell generates
> thumbnails automatically from the video content itself). Note that
> during the import of the memcard contents, I see errors such as:
> L 30416 2012-03-25 16:54:58 [DBG] VideoMetadata.vala:95: Error while
> testing for QuickTime file for
> /home/molsson/fuzzing/bugs/hdcamera_import_all/PRIVATE/AVCHD/BDMV/PLAYLIST/00000.MPL: 
>
> Unexpected early end-of-stream
> L 30416 2012-03-25 16:54:58 [DBG] VideoMetadata.vala:95: Error while
> testing for QuickTime file for
> /home/molsson/Pictures/2012/03/25/00000_1.CPI: Unexpected early
> end-of-stream
> L 30416 2012-03-25 16:54:58 [WRN] VideoSupport.vala:122: Unable to
> read video metadata: File
> /home/molsson/Pictures/2012/03/25/00000_1.CPI is not a supported video
> format...and hence it might just be that you need to respond to such
> an error by not creating a thumbnail. The real video file in this case
> is the .MTS file.

Ticketed at http://redmine.yorba.org/issues/4943 .

>
> *** While processing large images on machines with little RAM,
> Shotwell crashes instead of "failing to show the image and/or complete
> the operation but otherwise maintaining its composure". For example,
> on my laptop with 2GB RAM, I can import this image, but if I select
> the imported image in the library and press the ENHANCE button, then
> Shotwell crashes:
> http://temp.minimum.se/shotwell_issues/white-d21600x21600.jpg
> This image is just little over 21k times 21k which is not really that
> large (~1.8GB of pixel bytes); many photostitchers and (very) high end
> cameras generate such images. I also noticed that I can emulate this
> exact crash on my dev machine (with lots of memory), by start a
> terminal and running "ulimit -v 3000000 ; ./shotwell", then importing
> the file, then selecting it in the library and then pressing ENHANCE.
> The crash I see in both cases is a !=NULL assert at:
> #3  0x00d56eae in g_assertion_message (domain=0x0, file=0x851b450
> "/home/molsson/src/shotwell/src/Photo.vala", line=3140, func=0x851fa42
> "photo_get_pixbuf_with_options", message=<optimized out>) at
> /build/buildd/glib2.0-2.31.22/./glib/gtestutils.c:1860
> #4  0x00d574af in g_assertion_message_expr (domain=0x0, file=0x851b450
> "/home/molsson/src/shotwell/src/Photo.vala", line=3140, func=0x851fa42
> "photo_get_pixbuf_with_options", expr=0x851c6cd "_tmp42_ != NULL") at
> /build/buildd/glib2.0-2.31.22/./glib/gtestutils.c:1871
> #5  0x0832f981 in photo_get_pixbuf_with_options (self=0x8aefb80,
> scaling=0xb2a9afa8, exceptions=PHOTO_EXCEPTION_NONE,
> fetch_mode=BACKING_FETCH_MODE_BASELINE, error=0xb2a9afbc) at
> /home/molsson/src/shotwell/src/Photo.vala:3140
> #6  0x0832e797 in photo_real_get_pixbuf (base=0x8aefb80,
> scaling=0xb2a9b03c, error=0xb2a9b050) at
> /home/molsson/src/shotwell/src/Photo.vala:3006
> #7  0x081d78c1 in photo_source_get_pixbuf (self=0x8aefb80,
> scaling=0xb2a9b03c, error=0xb2a9b050) at
> /home/molsson/src/shotwell/src/core/DataSourceTypes.vala:60
> #8  0x083cc6c5 in pixbuf_cache_baseline_fetch_job_real_execute
> (base=0x95092a8) at /home/molsson/src/shotwell/src/PixbufCache.vala:50
> #9  0x080bb6e6 in background_job_execute (self=0x95092a8) at
> /home/molsson/src/shotwell/src/threads/BackgroundJob.vala:123
> Now, I'm not suggesting that Shotwell should get full OOM safety, but
> graceful error paths for the (handful?) of code paths where Shotwell
> allocate really large amounts of memory would be nice so that even
> users with 2GB RAM can safely do "import all images in homedir" and
> possibly some other operations that allocate copies of the image etc
> (like I assume enhance does?) without worrying too much. It would be
> really cool if you could get to the stage where it's possible to run a
> large import, enhance and export round trip session for a sizable set
> of images of various large sizes, without actually crashing.

http://redmine.yorba.org/issues/4944

>
> *** When importing this image:
> http://temp.minimum.se/shotwell_issues/wilts_bus.jpg
> I get the following errors printed to the terminal:
> (shotwell:18573): LIBDBUSMENU-GTK-WARNING **: Could not parse '_Delete
> Tag "Wilts & Dorset Bus"': Error on line 1: Entity did not end with a
> semicolon; most likely you used an ampersand character without
> intending to start an entity - escape ampersand as &
> (shotwell:18573): LIBDBUSMENU-GTK-WARNING **: Could not parse 'Re_name
> Tag "Wilts & Dorset Bus"...': Error on line 1: Entity did not end with
> a semicolon; most likely you used an ampersand character without
> intending to start an entity - escape ampersand as &
> (shotwell:18573): LIBDBUSMENU-GTK-WARNING **: Could not parse 'Remove
> Tag "Wilts & Dorset Bus" From _Photos': Error on line 1: Entity did
> not end with a semicolon; most likely you used an ampersand character
> without intending to start an entity - escape ampersand as &
> ...this error can most likely be fixed with an extra call to
> g_markup_printf_escaped() or similar.
>
> *** The above bug can also be hit if you take any plain JPG, import
> it, select it, open "Add Tags" and enter "a&b".

Right.  This is http://redmine.yorba.org/issues/3987 .  We believe this 
may be an Ubuntu bug.

>
> *** "make -j8" fails to do proper dependency checking whereas "make"
> does it correctly. This is likely confusing with newbie developers
> that want to help out.

Right.  I hope we can switch to waf soon 
(http://redmine.yorba.org/issues/2783) which may improve the situation here.

>
> *** Shotwell calls Gst.init() but never bothers to call Gst.deinit()
> causing a (relatively harmless) memory leak.

Debatably worth fixing.  If you want to send a patch we'd probably 
accept it.

>
> *** Right-click an image, select "add tag", enter "blah". Right-click
> the "blah" node under "Tags" and select "rename", enter "a,b". Now you
> have a tag with a "," in the name. Now select the photo that has this
> tag and select "Modify tags", the dialog loads it as "a,b" but when
> you press OK it splits the tag into two tags. This is an escaping
> inconsistency.

Yeah, we should improve this situation.  See 
http://redmine.yorba.org/issues/4950 .

>
> *** If I launch (WARNING: make sure you dont loose data if you run
> this command!) Shotwell using:
> dconf reset -f /apps/shotwell/ ; rm -rf ~/.cache/shotwell/
> ~/.shotwell/ ; SHOTWELL_LOG_FILE=:console: SHOTWELL_LOG=1 ./shotwell
> Then I can see DirectoryMonitor.vala sniffing around in my homedir
> _before_ I even clicked OK in the welcome dialog (i.e. shotwell
> doesn't know yet if I want to "Import ~" or not). Is this really
> intended? The stuff I see is for example:
> L 24260 2012-03-25 15:35:48 [WRN] DirectoryMonitor.vala:912: Skipping
> hidden file/directory /home/molsson/blah/yada/.hiddenfile

http://redmine.yorba.org/issues/4951

>
> *** In Edit::Preferences::Plugins, if you click on ABOUT for some
> plugin and then LICENSE; then all of them show the license text
> "Shotwell is free software; you can redistribute it...". Shouldn't
> those be modified to say "PluginThisAndThat is free software; you can
> redistribute it"?

Perhaps, though I think this OK because all these plugins are currently 
built and distributed with Shotwell.  At some point we may separate the 
"extra" plugins into a separate package which gets build and distributed 
separately, at which point the license terms should change.

>
> *** FEATURE REQUEST: Noise reduction (i.e. if you were forced to crank
> up the ISO too high on the camera, then Shotwell should have some
> postprocessing magic that eases the pain).

This might be addressed by http://redmine.yorba.org/issues/1916 .  We 
should consider other noise reduction techniques too.

>
> *** Import a photo. After clicking OK on the "imported 1 photo"
> dialog, note that the ROTATE/ENHANCE/PUBLISH buttons are not grayed
> out, but still not clickable (no photo is selected so imo they should
> be grayed out).

http://redmine.yorba.org/issues/4952

>
> *** Import lots of photos so you have like 100 events. Click the
> events root node labelled "Events". Now hold down the DOWN arrow for
> like 15 seconds in a futile attempt at quickly moving the selection
> downward a couple of steps. What happens is that Shotwell expands the
> node for each year, month and event and this takes a bit of time which
> is fine ofc. The problem is that Shotwell keeps collecting and
> queueing new keyboard events while it is doing that, and this has the
> effect that even if the user releases the DOWN key, Shotwell will keep
> processing old keyboard events for a long long time. On my machine
> this results in Shotwell being grayed out as unresponsive and I have
> to wait 1-2 minutes before Shotwell becomes usable again depending on
> how long I held down the DOWN key. This is kind of a minor issue but a
> bit annoying. It would be better if Shotwell didn't accept and queue
> new keyboard events while it was expanding and showing an event node.

http://redmine.yorba.org/issues/4953

>
> *** Missing space char in debug print outs:
> http://temp.minimum.se/shotwell_issues/0001-Add-missing-space-in-debug-output.patch 
>
>
> *** Fix spelling s/sibbling/sibling/ in debug output:
> http://temp.minimum.se/shotwell_issues/0001-Fix-spelling-s-sibbling-sibling-in-debug-output.patch 
>

We committed these patches before shipping Shotwell 0.12.0.  Thanks.

>
> *** FEATURE REQUEST: Ability to rotate videos.

Already ticketed at http://redmine.yorba.org/issues/3073 .

>
> *** FEATURE REQUEST: Ability to upload to imgur.com (already requested
> in http://redmine.yorba.org/issues/2931 )
>
> *** This image makes it past the import but can't be viewed or exported:
> http://temp.minimum.se/shotwell_issues/importable_but_not_exportable.jpg
> The file is partially corrupt but is viewable in "eog" nevertheless.
> While Shotwell processes this file I see:
> L 20401 2012-03-25 13:41:14 [CRT] PixbufCache.vala:262: Unable to
> readahead [1]
> /home/molsson/fuzzing/bugs/importable_but_not_exportable/importable_but_not_exportable.jpg: 
>
> Failed to load image
> '/home/molsson/fuzzing/bugs/importable_but_not_exportable/importable_but_not_exportable.jpg': 
>
> Error interpreting JPEG image file (Unsupported marker type 0x64)
> L 20401 2012-03-25 13:41:14 [CRT] data_collection_mark: assertion
> `IS_DATA_OBJECT (object)' failed
> L 20401 2012-03-25 13:41:14 [CRT] view_collection_select_marked:
> assertion `IS_MARKER (marker)' failed

http://redmine.yorba.org/issues/4954

>
> *** In Edit::Preferences::Library, "Directory structure:" and
> "Default:" share the same mnemonic. In older GTK versions this caused
> CTRL-D presses to alternate between the two but right now none of them
> gets focused.

Thanks - ticketed at http://redmine.yorba.org/issues/4934 .  We'll fix 
this for 0.12.1.

> Also the ALT-P mnemonic doesn't work at all, not even
> after selecting CUSTOM in the "Directory structure" field.

Thanks.  We fixed this in time for 0.12.0.

>
> *** UI consistency: The PUBLISH wizard pages for facebook, picasa and
> flickr
> has different UI padding; looks a bit inconsistent.

We know.  All those pages are currently laid out manually using GTK 
calls.  We want to move their layout to Glade 
(http://redmine.yorba.org/issues/3205) which will make it much easier to 
maintain them and make them look consistent.

>
> *** Disable all plugins and then select "import from app" in file
> menu, the dialog explains you got no plugins, but when this dialog is
> closed Shotwell prints this error:
> L 8214 2012-03-13 20:00:36 [CRT]
> spit_data_imports_plugin_host_stop_importing: assertion
> `SPIT_DATA_IMPORTS_IS_PLUGIN_HOST (self)' failed

http://redmine.yorba.org/issues/4955

>
> *** UI/USABILITY FEEDBACK: The welcome dialog says "Import photos from
> your ~ folder". There are probably quite a new novice Linux users that
> do not know what ~ means, perhaps it should say "home folder" instead?

http://redmine.yorba.org/issues/4956

>
> *** UI/USABILITY FEEDBACK: Suppose a user wants to select all photos
> from an event and use the "Enhance" functionality on them. This, and
> also rotate, doesn't work if there is at least one video included in
> the event (i.e. if at least one video is selected the ROTATE/ENHANCE
> buttons will be disabled/unclickable). There is no cue or hint in the
> UI that explains to the user why those buttons are no longer
> clickable. Here are some ideas for fixing this A) when the button is
> disabled due to this particular reason, then change the button tooltip
> to say "Rotation is not available when one or more videos are
> selected", or B) have the button enabled and rotate/enhance only the
> photos, silently ignoring the videos that happened to be selected as
> well (this would weird, especially if the user selects _only_ videos
> although ofc one could make the rotate/enhance buttons be disabled for
> that particular case), C) show a warning/confirm dialog saying that
> "you have one or more videos selected; these will not be
> rotated/enhanced", D) come up with something even better! Also, as
> long as Shotwell has this constraint, it might be useful to have a
> "Select all photos" menu item next to the "Edit::Select All", which
> doesn't just help to alleviate the unable-to-enhance-all problem, it's
> also somewhat useful for cases where one wants to PUBLISH only the
> photos from an event and not the videos.

http://redmine.yorba.org/issues/4958

>
> *** At first I found it a bit confusing that File::Export and
> "File::Send To" gives me the exact same _export_ dialog. It would be
> easier to understand if the "Send To" dialog was just a single big
> dialog containing both the "format" stuff and the "send to target"
> stuff. However, since the "Send To" dialog is a GNOME dialog, this
> might not be easy to do.

Yes - it is a GNOME dialog so this might not be easy.

Thanks again for all your feedback, Martin!

adam