F-Spot import creates both top-level and hierarchical tags if tags present in files
Submitted by Adam Dingle
Assigned to Lucas Beeler
Link to original bug (#717970)
Description
---- Reported by adam@yorba.org 2011-08-31 01:12:00 -0700 ----
Original Redmine bug id: 4081
Original URL: http://redmine.yorba.org/issues/4081
Searchable id: yorba-bug-4081
Original author: Adam Dingle
Original description:
Suppose that an F-Spot user has enabled the preference to store tags inside photo files, and that the user has created hierarchical tags in F-Spot. When Shotwell imports from the F-Spot database, it will create two copies of each hierarchical tag: one inside the tag hierarchy and one at top level. This makes F-Spot import pretty much unusable for any F-Spot user who's storing tags inside photo files (as many users do, I'm sure.)
I hope we can find some solution to this for 0.11.1. Perhaps when importing from F-Spot we can ignore tags present in the photo files and only use tags from the F-Spot database. I fear, however, that the Shotwell startup scan might notice the non-hierarchical tags in the photo files (F-Spot doesn't write out the tag hierarchy to photo metadata, by the way) and once again try to recreate the top-level tags. If that's the case, we may need to implement #4051 at least partially in order to fix this.
Related issues:
- related to shotwell - 4051: imported non-hierarchical tag should match existing hiera... (Fixed)
- related to shotwell - 4074: When metadata writing is turned on, reimport can cause HT... (Fixed)
- related to shotwell - 4090: crash after f-spot import. (Fixed)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
History
Comment 1
Updated by Jim Nelson about 2 years ago
Lucas believes this might be related to #4074 (closed). Hopefully we can knock these two (and possibly #4071) out in one go.
Comment 2
Updated by Jim Nelson about 2 years ago
- Category set to 4
- Assignee set to Lucas Beeler
Comment 3
Updated by Lucas Beeler about 2 years ago
- Status changed from Open to 5
- Resolution set to fixed
Fixed in c59cc117 and 2aca7356
Comment 4
Updated by Adam Dingle about 2 years ago
- Status changed from 5 to Open
- Target version changed from 0.11.1 to 0.11.2
-
Resolution deleted (
<strike>
_fixed_</strike>
)
A user on the mailing list reported that this bug was still present in 0.11.1. I just tried this myself and he's right: the bug is still there. To see this:
-
In F-Spot, make sure that the option "Store tags and descriptions -> Inside the image files" is on.
-
In F-Spot, create a parent and a child tag. Assign the parent tag to one photo and the child tag to another.
-
Import into Shotwell. Shotwell will create the child tag twice: both in its proper position and also at top level.
Comment 5
Updated by Jim Nelson about 2 years ago
The user has supplied screenshots, EXIF dumps, and sample files here:
http://lists.yorba.org/pipermail/shotwell/2011-September/002950.html
Comment 6
Updated by Jim Nelson about 2 years ago
- Assignee changed from Lucas Beeler to Clinton Rogers
Lucas is having trouble reproducing this at home. We've asked the reporter to send a full Shotwell log. In the meantime, I've asked Clinton to attempt to reproduce this here in the office.
Comment 7
Updated by Jim Nelson about 2 years ago
- Assignee changed from Clinton Rogers to Lucas Beeler
Just as I wrote the last entry the reporter wrote back that he now couldn't reproduce the problem, but after a little investigation realized what was going on:
http://lists.yorba.org/pipermail/shotwell/2011-September/002966.html
Reassigning to Lucas, as now we should have enough information to reproduce this behavior in house. From his description it seems there is still an issue when multiple metadata fields are filled in with keywords from F-Spot.
Comment 8
Updated by Lucas Beeler about 2 years ago
- Status changed from Open to 5
- Resolution set to fixed
Very subtle, but fixed in 55f54e6c
Comment 9
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Fixed
--- Bug imported by chaz@yorba.org 2013-11-25 21:54 UTC ---
This bug was previously known as bug 4081 at http://redmine.yorba.org/show_bug.cgi?id=4081
Unknown Component Using default product and component set in Parameters Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Version: 0.11.2
Resolution: RESOLVED FIXED