Keyboard navigation in darkroom skips/loops over a subset of images if a color rating is selected through collect images on Fedora
This issue was encountered on Fedora 25 with darktable 2.2.0~rc2 and appears to be reproducible for this image set.
- Sort images by date and time
- Assign color ratings to images
- Collect images by a given color rating
- Double-click on the first image to enter the darkroom view
- Press space to navigate to the next image, which is not the next image on the filmstrip
A quick, if inefficient fix, would be to request all rows in the result set, rather than the first one. However, there also seems to be an underlying issue somewhere.
It appears that limiting result row count to 1 in dt_dev_jump_image within darkroom.c in conjunction with the color rating filter yields an image id that fulfills the flag and color label criteria, but does not fulfill the order by criteria. Changing the row count to something larger (e.g., -1 or 7) does seems to yield the correct next image ID.
The same behavior can be replicated when interacting with the SQLite database file directly.
For example, using the SQL dumped from sqlite3_expanded_sql as called from darktable,
select id from main.images where (flags & 256) != 256 and (id in (select imgid from main.color_labels where color = 0)) order by datetime_taken, filename, version
yields 1379, 1382, 1385 ...
If one were to enter the darkroom view with the first image,
select imgid from main.selected_images
The offset as determined by dt_collection_image_offset in collection.c is 0, as expected.
The following should yield the next image
select id from main.images where (flags & 256) != 256 and (id in (select imgid from main.color_labels where color = 0)) order by datetime_taken, filename, version limit 1,1
but returns 360, not 1382.
select id from main.images where (flags & 256) != 256 and (id in (select imgid from main.color_labels where color = 0)) order by datetime_taken, filename, version limit 1,-1
does yield 1382, 1385...
This issue was also present in the 2.0.7 release from the Fedora repositories, but could not be reproduced with the git master branch in Ubuntu 16.04.1 LTS using a different set of photos. Cycling through photos without filtering by color rating did result in sequential navigation.
#1 Updated by S W about 3 years ago
Similarly, there appears to be an issue where the limit component is filtering out certain images (that would be returned if the row limit were set to -1) via _lib_filmstrip_draw_callback in filmstrip.c. In this case, an image can be opened from lighttable, but not appear on the filmstrip in darkroom.
libsqlite3.so.0 from /lib64/libsqlite3.so.0 appears to be linked for darktable and the standard sqlite package is installed.
#3 Updated by S W about 3 years ago
3.14.2 from 2016-09-12. According to [[https://www.sqlite.org/releaselog/3_15_0.html]], the issue was fixed in the next release from 2016-10-04, but 3.14.2 per [[https://apps.fedoraproject.org/packages/sqlite]] is the latest generally available package for Fedora 25.
For release 3.15.0 onwards:
Make sure the ORDER BY LIMIT optimization (from check-in 559733b09e) works with IN operators on INTEGER PRIMARY KEYs. Fix for ticket 96c1454c
#7 Updated by S W about 3 years ago
Germano Massullo wrote:
Open a bugreport at https://bugzilla.redhat.com/ against sqlite component