After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 719142 - Assertion failure on removing photo from last import roll
Assertion failure on removing photo from last import roll
Product: shotwell
Classification: Other
Component: import
Other All
: High normal
: 0.28
Assigned To: Shotwell Maintainers
Shotwell Maintainers
: 723052 773183 (view as bug list)
Depends on:
Reported: 2013-09-13 11:10 UTC by Charles Lindsay
Modified: 2017-10-03 18:53 UTC
See Also:
GNOME target: ---
GNOME version: ---

The state of raw development does not affect filtering anymore. (3.45 KB, patch)
2017-08-30 19:38 UTC, Stefan
committed Details | Review

Description Charles Lindsay 2013-11-25 21:59:47 UTC

---- Reported by 2013-09-13 16:10:00 -0700 ----

Original Redmine bug id: 7487
Original URL:
Searchable id: yorba-bug-7487
Original author: Joe Bylund
Original description:

I imported a single file from an sd card, then deleted the file and I got the
following assertion failure, I can't immediately reproduce.

    ERROR:/home/jbylund/Desktop/git/shotwell/src/MediaViewTracker.vala:72:media_accumulator_real_uninclude: assertion failed: (photos > 0)

---- Additional Comments From shotwell-maint@gnome.bugs 2013-10-03 18:22:00 -0700 ----

### History



Updated by Jim Nelson 2 months ago

  * **Category** set to _import_



Updated by Jim Nelson about 1 month ago

  * **Target version** deleted (<strike>_0.15.0_</strike>)

--- Bug imported by 2013-11-25 21:59 UTC  ---

This bug was previously known as _bug_ 7487 at

Unknown version " in product shotwell. 
   Setting version to "!unspecified".
Unknown milestone "unknown in product shotwell. 
   Setting to default milestone for this product, "---".
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here:
   Previous reporter was
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
Resolution set on an open status.
   Dropping resolution 

Comment 1 Joe Bylund 2014-01-28 00:10:01 UTC
*** Bug 723052 has been marked as a duplicate of this bug. ***
Comment 2 Joe Bylund 2014-01-28 00:11:21 UTC
There's another report which looks somewhat similar here:  It's for a much older version of the code, but does contain a backtrace.
Comment 3 Jim Nelson 2014-01-28 00:13:11 UTC
There's also a stack trace at, thread #1.
Comment 4 Jens Georg 2016-10-31 16:17:39 UTC
*** Bug 773183 has been marked as a duplicate of this bug. ***
Comment 5 Jens Georg 2017-01-21 10:10:02 UTC
*** Bug 777564 has been marked as a duplicate of this bug. ***
Comment 6 Stefan 2017-08-25 19:34:49 UTC
For me, this is one of the most annoying issues. I'll try to solve it.
Comment 7 Stefan 2017-08-29 20:33:09 UTC
For documentation:

I can be reproduce this by 2 ways.
The pre-conditions:
* RAW Developer: Camera
* RAW+JPEG pair

First way (the easy one):
* Import 20 RAW+JPEG pairs from the camera and wait until the import is complete and the page "Last Import" is successfully loaded.
* Select a random (or all) photo on the last import page (do not navigate in the tree) and delete the selected items.
* Shotwell will crash (MediaViewTracker.vala:72:media_accumulator_real_uninclude: assertion failed: (photos > 0))

Second way (you need the right timing)
* Import 20 RAW+JPEG pairs from the camera and wait, until the import is complete and the page "Last Import" is successfully loaded.
* Navigate quickly to the event and delete all photos.
* Shotwell will crash (MediaViewTracker.vala:72:media_accumulator_real_uninclude: assertion failed: (photos > 0))

The problem seems to be the RAW development in the background. The MediaAccumulator counts 0 photos but 20 RAW after the include operations. 0 photos, because photo.is_raw_developer_available(RawDeveloper.CAMERA) still returns false.

When you remove the image, then, photo.is_raw_developer_available(RawDeveloper.CAMERA) returns true and the uninclude method tries to remove a photo. But assert(photos > 0) is false.
Comment 8 Stefan 2017-08-30 19:38:48 UTC
Created attachment 358792 [details] [review]
The state of raw development does not affect filtering anymore.

Primarily, the counter for photos, videos, and raw in MediaViewTracker affects the enabled/disabled state of the corresponding filter buttons.

Solving this issue needs a short discussion about the role of the condition photo.is_raw_developer_available(RawDeveloper.CAMERA) when counting photos/raw or doing the filtering for photos/raw. 
From my point of view, this condition is not necessary and leads to a misleading behavior during filtering

Actual behavior:

An event contains a JPEG, a RAW only and a RAW+JPEG photo
Filtering photos shows: JPEG and RAW+JPEG
Filtering RAW shows: RAW only and RAW+JPEG

What I would expect:

Filtering photos should show: JPEG, RAW only and RAW+JPEG
Filtering RAW should show: RAW only and RAW+JPEG

The question:
What’s the reason, that Shotwell doesn’t show RAW only when filtering for photos. A RAW photo is still a photo.

This is, why I think that photo.is_raw_developer_available(RawDeveloper.CAMERA) is not necessary for filtering.

The expected behavior is reached by the attached patch
Comment 9 Jens Georg 2017-08-31 06:36:10 UTC
Thanks, I will have a deeper look later.

I _think_ the intention was to say "which has a development". It might be a side effect of RAW being somewhat "bolted onto" Shotwell.
Comment 10 Jens Georg 2017-10-03 18:53:09 UTC
Comitted with minor re-formatting of the commit message