Version: rev: 861503 (using KDE 4.1.1) OS: Linux Installed from: Unspecified Linux When upgrading digikam collection from 0.9.x to 0.10, all tag names which are longer than: /location/nation/japan/hiroshima/ prefecture/miyajima/mt misen/dai gets cut off. I have opened the databases and confirmed that the tag name is cut in digikam4.db and complete in the digikam3.db. However if I manually edit tags in digikam 0.10 then I am allowed to store larger tag names (deeper nested tags).
Sound like tags are cuts to 64 char. Sound like tags are imported from IPTC. Are you imported images as well ? Where is digikam3.db when you import a repository ? Gilles Caulier
(In reply to comment #1) > Sound like tags are cuts to 64 char. Sound like tags are imported from IPTC. > > Are you imported images as well ? Where is digikam3.db when you import a > repository ? > > Gilles Caulier > I have tried with digikam3.db in the same location as digkam4.db is stored as default and as a custom path later. Images are stored with the same directory hierarchy in both versions. I do agree that it does sound like tags are imported from IPTC, but on closer inspection all I can see in digikams IPTC tab is the following: Keywords : location, sport, location/nation/japan/hiroshima prefecture, location/nation/japan/hiroshima prefecture/miyajima, location/natio... (In reply to comment #1) > Sound like tags are cuts to 64 char. Sound like tags are imported from IPTC. > > Are you imported images as well ? Where is digikam3.db when you import a > repository ? > > Gilles Caulier >
After numerous reinstallation and attempts to imports old tag data, I suddenly have complete tag names. I have not done anything different. Only removed and reinstalled digikam, same build from same revision. You were correct it did only load the IPTC data as I now have both the cut tags and the complete ones from digikam3.db. Maybe there should be an option to chose from where digikam should read tag data: IPTC, the old database or both? I will reinstall and reimport a couple of more times to see if I can find out what happened and what changed.
The database must be the first way to take tags, because there is no limitation (size and char encoding). IPTC is a mess, but at least it work a bit. With digiKam 0.10.0, we support XMP everywhere. There is no limitation to store tags in XMP. this problem will disapear. It just a transitional problem in fact between KDE3 and KDE4 version Gilles Caulier
In Sindre's first attempt, obviously the digikam3.db file was not found and not upgraded for whatever reason I cannot find out. The second attempt highlights a problem with reading tags for which there is no satisfactory solution: When a file is fully rescanned (all files will after database upgrade, or when manually requested), tags will be rescanned as well. When there are cut IPTC tags, they will be created as new. Note that when a file modification is detected, there is no full rescan of metadata, to avoid situations like this, cut tags popping up again. In both situations, there cannot be a perfect solution, because one user will explicitly want his tags scanned, while the other certainly wants to avoid that. So we do it once at import.
I would suggest to close the bug report unless we can establish a condition where the old database is reproducibly not found. Sindre, any more updates, or does it work for you now?
somebody stole the T in the bugreport title... :-)
Sindre, digiKam 0.10.0-beta6 is out. Please, give us a fresh feedback about your problem. thanks in advance Gilles Caulier
Ok. thanks. Gilles Caulier