GNOME Bugzilla – Bug 752286
Reload key picture for events
Last modified: 2017-09-19 17:19:13 UTC
After reinstalling my system and copying back my backup files, Shotwell does not show the key pictures for the events anymore. I found a solution via google, but it is not very good: I have to open the event, zoom to the highest preview level for the thumbnails of the pictures in this event, then browse all pictures, go back to standard zoom level and leave the event. After that, the key picture for the event is shown again. Unfortunately I have to do this for all events, which is a lot of work if the picture library is large. I think this does not happen very often, but when it happens it's very annoying. Can you please fix this or maybe add an option to reload/refresh those key pictures/thumbnails? I use Fedora 22 (64bit) with Cinnamon desktop environment.
Same here, with Archlinux and Shotwell 0.24.5, Xmonad desktop manager.
I would like to add some information to the issues regarding key photos / primary photos of events. Similar bugs: bug 748666, bug 719260 - ressources: wiki.gnome.org/Apps/Shotwell/Architecture/Database I am using ubuntu 14.04lts and shotwell 0.18. When I look at the database (/home/<user>/.local/share/shotwell/data/photo.db via SQLite database browser) in the EventTable I see the id, the name of the event and additionally two columns: - primary_photo_id (which is empty) - primary_source_id (which contains expressions like these: thumb0000000000000a89 - I call it "thumb-id") I would say primary_source_id points to files in the sub-folders of /home/<user>/.cache/shotwell/thumbs. If you omit to copy these files to a new system it is likely Shotwell will generate different thumb-ids on the new system on the fly and you will end up with different key photos. (simple solution: copy this folder to the target system too) I experimented on the two columns: when emptying primary_source_id and inserting a valid id from the PhotoTable to primary_photo_id the behaviour is as expected. Shotwell shows the photo associated with this id correctly (as far I tested). I wonder why Shotwell is not using this way by default to determine the key photos. Rather it is relying on the thumbs. Without knowing the details, I think using primary_photo_id instead of primary_source_id should fix the problems described in the referenced bugs permanently and make Shotwell more resilient. Further I wondered why the PhotoTable does not contain an additional column that stores the thumb-id. In the PhotoTable exits the column filename (which contains values like: /home/px/2007/2007-02-10/p0374.jpg). If there would be such a column "thumb-id" containing the value thumb0000000000000a89 (corresponding to the EventTable.primary_source_id) there would be a good chance to get a new thumb-id together with the filename ;) Independently from this problem I would like to thank you very much for this very fine piece of software!
Yes, the database design is interesting in parts and I still have not really understood it completely. Incidently, since tags are bound to thumbs as well (I have no clue why), you will also break tags. Thanks for your analysis, much appreciated since I'm not the original author and also struggle to understand the flow of many codeparts
> I would say primary_source_id points to files in the sub-folders of > /home/<user>/.cache/shotwell/thumbs. If you omit to copy these files to a > new system it is likely Shotwell will generate different thumb-ids on the > new system on the fly and you will end up with different key photos. (simple > solution: copy this folder to the target system too) I think I have reconstructed that: primary_photo_id was used before Shotwell supported videos. If you put a value in there, it will be converted to the primary_source_id format. The primary source id is make of <type-prefix><value of primary_photo_id_in_hex> and is also used for the thumbnail names. For some reason, the prefix for a photo is "thumb", and for a video it's "video-". > I experimented on the two columns: when emptying primary_source_id and > inserting a valid id from the PhotoTable to primary_photo_id the behaviour > is as expected. Shotwell shows the photo associated with this id correctly > (as far I tested). > > I wonder why Shotwell is not using this way by default to determine the key > photos. Rather it is relying on the thumbs. Without knowing the details, I > think using primary_photo_id instead of primary_source_id should fix the > problems described in the referenced bugs permanently and make Shotwell more > resilient. See above. it isn't. I also thought it is, but that's just an odd way to solve a problem with the database design. Or rather work around it.
*** This bug has been marked as a duplicate of bug 748666 ***