So I upgraded to Ubuntu 16.04 to be able to test Digikam 5beta6. After the upgrade, I started Digikam 5 and was a little surprised that it did not offer to import / migrate / update the Digikam 4 database I already had, but behaved like a new installation. (Is this intentional during the beta phase so that production (Digikam 4.14) and testing (Digikam 5) can be kept separate?) Since digikam did not detect my Digikam4 library I went to Settings > Database Migration and clicked "Migrate" with the default settings (SQlite format and the same path on both sides, after all, Digikam 5 did not find my library, so it probably uses another file name!) But it didn't work, even afterwards Digikam did not find my library. What's more, after closing and reopening Digikam 4.14, it did not display any photos - and all my locations, tags, album comments and so on were gone!!! It seems they were deleted from digikam4.db; the "Tags" table was empty, so was the "Settings" table and some others. IMHO there should be no way of doing this. Digikam should warn before overwriting data or modifying it so that an old version cannot read it any more. (Was this even the right procedure to get Digikam 5 set up?) Reproducible: Always
No. digiKam 5 ans Sqlite DB still exactly the same. Nothing has changed. DB file is the same that digiKam 4.x. SQL schema for Sqlite still untouched. The update from a 4.x to a 5.x do not require a migration. The problem is in your computer settings. Gilles Caulier
"My Computer Settings" - a.k.a. Digikam 5 - permit overwriting digikam4.db with the exact same file (digikam4.db) in the migration dialog. I think this is the problem. Can you please verify and if so, add a check that the migration database files must be different. Thanks!
Why do you talk about "migration" to import DK sqlite database from version 4 to 5 ? As i said before, it'z the same file ! There is nothing to migrate. Just configure DK 5 as DK 4. that all... Migration tool is to switch from one DB type to another and different one. Not to the same DB type from original to target. Gilles Caulier
Let me explain. Digikam 5 (beta6), when started first, did not recognize my existing albums and collections from Digikam 4.14 (on Ubuntu Linux) and just showed me a welcome and setup screen. So I logically assumed there must be a migration procedure. (This I would consider a bug - if there are previous existing collections, a new version of Digikam should just open them or offer to import them.) I found the migration option and selected my digikam4.db (the target was already preselected) and started the migration. This destroyed the digikam4.db tables as described below so subsequent starts of Digikam 4.14 wouldn't show tags etc. any more. Starting the migration might have been my mistake but a user friendly application should prevent users from doing something stupid (like starting a migration when it isn't required or possible) so I consider this a bug too. The solution is simple: upon start, just load the digikam4 config (if available) and - if required - copy it to a digikam5 config. And when a user starts the Migration task from the maintenance menu and selects database files or formats which cannot be migrated, show an appropriate error message and refuse the migration. Do you agree?
>Digikam 5 (beta6), when started first, did not recognize my existing albums and >collections from Digikam 4.14 (on Ubuntu Linux) and just showed me a welcome and >setup screen. So I logically assumed there must be a migration procedure. No. The reason why the old collection is not recognized (and first run assistant launched) is the location of digikamrc file including all DK configuration which have been moved from ~/.kde4/share/config to ~/.config which is the standardized place under Linux. If you copy this file at this place all will start as expected. In all cases, the migration option is not the right way to process. It's right than no rule to copy old digikamrc file from old place to new one is not implemented. But, starting with a new fresh DK setup and configure the collections and the place where the database is stored will normally not touch the DB content and all will be available as with 4.x release. Gilles Caulier
> If you copy this file at this place all will start as expected. Do you expect a normal user (= non-geek, non-programmer) to know that? Then this is a usability issue, not a technical one. But an important one. Or is Digikam not meant to be used by non-geeks? > In all cases, the migration option is not the right way to process. How should a user know? He can't. So prevent the migration from being abused in this case. Users should not be able to perform tasks that destroy data, otherwise they lose their trust in the application. > But, starting with a new fresh DK setup and configure the collections and the place where the database is stored will normally not touch the DB content and all will be available as with 4.x release. OK, but - again - (how) do you expect a normal user (= non-geek, non-programmer) to know that? From a usability perspective, Digikam5 should proactively offer to import all Digikam4 settings, collections and so on - no matter where they were saved previously. Nobody wants to research how to do this manually, even if it is possible. Please don't get me wrong, I like Digikam a lot and I want it to be successful. This is why these things are so important to me.
I confirm that older place of digikamrc file from .kde4 is not backported in new .config at first run of 5.0.0. There is a copy method in KDE AP : https://api.kde.org/frameworks/kconfig/html/classKConfig.html#adff2a11187952db0c4ad5fbff0c11bad Gilles Caulier
Files to backport under Linux : - ~/.kde4/share/config/digikamrc - ~/.kde4/share/config/digikam_tagsmanagerrc - ~/.kde4/share/config/kipipluginsrc - ~/.kde4/share/config/kipirc - ~/.kde4/share/config/showfotorc - ~/.kde4/share/apps/digikam/ New place under Linux : - ~/.config/digikamrc - ~/.config/digikam_tagsmanagerrc - ~/.config/kipipluginsrc - ~/.config/kipirc - ~/.config/showfotorc - ~/.local/share/apps/digikam/* Gilles
Files to backport under OSX : - ~/Library/Preferences/KDE/share/config/digikamrc - ~/Library/Preferences/KDE/share/config/digikam_tagsmanagerrc - ~/Library/Preferences/KDE/share/config/kipipluginsrc - ~/Library/Preferences/KDE/share/config/kipirc - ~/Library/Preferences/KDE/share/config/showfotorc - ~/Library/Preferences/KDE/share/apps/digikam/ New place under OSX : - ~/Library/Preferences/digikamrc - ~/Library/Preferences/digikam_tagsmanagerrc - ~/Library/Preferences/kipipluginsrc - ~/Library/Preferences/kipirc - ~/Library/Preferences/showfotorc - ~/Library/Preferences/share/apps/digikam/* Gilles
Files to backport under WINDOWS : - ~/AppData/Local/digikamrc - ~/AppData/Local/digikam_tagsmanagerrc - ~/AppData/Local/kipipluginsrc - ~/AppData/Local/kipirc - ~/AppData/Local/showfotorc - ~/AppData/Local/digikam/ New place under WINDOWS : - ~/Local Settings/digikamrc - ~/Local Settings/digikam_tagsmanagerrc - ~/Local Settings/kipipluginsrc - ~/Local Settings/kipirc - ~/Local Settings/showfotorc - ~/Local Settings/digikam/* Gilles
That's amazing! The bug is there for a month and I guess the developers understand its consequences and the fix is not very complex. Guess what? I've just overwritten my old digikam4.db in the migration dialog without digikam asking for any confirmation. Years of tags are lost. Well done digikam devs!
Alexey, This is not implemented because we seen that old digikam 4.x settings from digikamrc file crash violently the application and we haven't yet identified which one exactly. You must always make a backup of your database before a major update. Gilles Caulier
Backups are a must anyway. (IMHO: Just install deja-dup and setup some remote storage (a NAS or a cloud service) and stop thinking about it.) Specifically, did you narrow down your search about 4.x settings digikam 5 so that I can help doing some bisect testing?
Also which bug report is about these crashes?
This one for ex : https://bugs.kde.org/show_bug.cgi?id=365079 Gilles Caulier
(In reply to caulier.gilles from comment #8) > Files to backport under Linux : > > - ~/.kde4/share/config/digikamrc > ... > - ~/.kde4/share/apps/digikam/ > > New place under Linux : > > - ~/.config/digikamrc > ... Here the migration was failed. It has removed all the databases entries :( Here is a sample of messages when it scan the databases the 1st run : digikam.database: Creating new Location "/" uuid "volumeid:?path=%2Fhome%2Fdomi%2FPhotos" digikam.database: location for "%2Fhome%2Fdomi%2FPhotos" is available true KMemoryInfo: Platform identified : "LINUX" KMemoryInfo: TotalRam: 8376160256 digikam.general: Allowing a cache size of 200 MB digikam.thumbsdb: ThumbDB SelectThumbnailSetting val ret = 0 digikam.thumbsdb: ThumbDB SelectThumbnailSetting val ret = 0 digikam.thumbsdb: Thumbs database: have a structure version "3" digikam.general: Thumbnails database ready for use digikam.database: Removed items: (1, 2, 3, 4, 5, 6) related items: () digikam.database: Removed items: (9) related items: () digikam.database: Removed items: (15747, 15945, 16033) related items: () digikam.database: Removed items: (2410, 2411, 2412, 2413, 2414, 2415, 2416, 2417, 2418, 2419, 2420, 2421, 2422, 2423, 2424, 2425, 2426, 2427, 2428, 2429, 2430, 2431, 2432, 2433, 2434, 2435, 2436, 2437, 2438, 2439, 2440, 2441, 2442, 2443, 2444, 2445, 2446, 2447, 2448, 2449, 2450, 2451, 2452, 2453, 2454, 2455, 2456) related items: () ... digikam.database: Removed items: (16304, 16305, 16306, 16307, 16308, 16309, 16310, 16311, 16312, 16313) related items: () digikam.database: Folder does not exist or is not readable: "%2Fhome%2Fdomi%2FPhotos" Now, when it starts, I have this message : digikam.database: Folder does not exist or is not readable: "%2Fhome%2Fdomi%2FPhotos" Why %2F in place of slash ? it should be /home/domi/Photos" ??!!! in digikamrc file, the path is correct : Album Path=/home/domi/Photos Database File Path=/home/domi/Photos I have migrated another user successfully, and his folder appears correctly with slash in path not %2F... I think it's a clue.
I think as well that the current non-existing migration process from digikam 4 to 5 is pretty user unfriendly. I wondered also why I had to reconfigure everything and my templates were gone. After some searching, I found this bug. At least, my database wasn't fucked up. Since several bad experiences with digikam breaking its db, I'm very cautious in this regard. I would have expected at least a piece of information somewhere that the config paths changed. It shouldn't be so hard to implement a notice in the first-run wizard. Alternatively, one could ask the user if he did use digikam 4 before and if so, display some warnings. You could explain that the config path did change and that the files can be copied by the user at own risk. Furthermore, is there any reason why you do not make a copy of digikam4.db and save it as digikam5.db (although the db didn't change)?
Created attachment 100439 [details] Add information about configuration transition to welcome screen. I agree that this is a very important point for the user. Of course ideally the transition problems would be removed, but as always: This is open-source, if you want it done, do it. I attached a patch that adds information about the (non-)migration of the configuration to the welcome screen.
Thanks Simon for your patch. Gilles Caulier
Hi Gilles, Do you plan to include this or something similar before the 5.1.0 release? This is a major reason why digikam 5 is still in the experimental repository on debian. The "compatibility break" without any notice is considered a major issue for the user. Cheers, Simon On 04/08/16 12:01, via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=364258 > > caulier.gilles@gmail.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Summary|Upgrade to 5.0 (beta6) |Upgrade to 5.0 (beta6) > |:KDE4 application |:KDE4 application > |configuration rc files |configuration rc files > |ignored |ignored [patch] > > --- Comment #19 from caulier.gilles@gmail.com --- > Thanks Simon for your patch. > > Gilles Caulier >
Git commit af3309fe913933fcbc9fd05066ee56e0260e195f by Maik Qualmann. Committed on 05/08/2016 at 18:41. Pushed by mqualmann into branch 'master'. apply patch #100439 from Simon to add information about configuration transition to welcome screen M +20 -5 utilities/assistants/firstrun/welcomepage.cpp http://commits.kde.org/digikam/af3309fe913933fcbc9fd05066ee56e0260e195f
Git commit c2c7c2a00371254a395fc915188adc39c99844a8 by Gilles Caulier. Committed on 06/08/2016 at 06:35. Pushed by cgilles into branch 'master'. Be more precise about places where old settings files are installed for MacOS, Windows and Linux. M +17 -4 utilities/assistants/firstrun/welcomepage.cpp http://commits.kde.org/digikam/c2c7c2a00371254a395fc915188adc39c99844a8
Hi all, I was unable to save my database (sqlite) even with digikam 5.1.0. I finally found out a workaround to this issue. Comment:16 by hamelg is the key to this. 0. I am assuming you are upgrading from digikam-4 to digikam-5, and the database files were using sqlite. 1. Make sure you backup digikam4.db and thumbnails-digikam.db 2. Start digikam-5 and let it go through the welcome dialog and "forget" all the image information. I am using this step to make digikam create the digikamrc file with the correct path to images and database. Quit digikam. 3. Install sqlitebrowser. 4. Copy the backed up digikam4.db and thumbnails-digikam.db to the album folder. 5. Open digikam4.db using sqlitebrowser. 6. In sqlitebrowser, navigate to "Browse data", and double click on the "volumeid:?pat.." that shows up. Edit the path to replace all "%2F" with "/". Click "Ok". Then click on "Write Changes" and quit sqlitebrowser. 7. Open digikam again. This time it should show all the images and tags. Hope this helps someone. It worked for me. Cheers!
Created attachment 101393 [details] Support to migrate digiKam 4 settings/database in the first run wizard I've implemented this patch that adds a new page to the FirstRun wizard that allows the user to choose if he/she wants to do a migration of the digikam4 settings (only if settings from digikam4 are detected). If the user selects to create new settings, then the usual wizard continues, and if the user selects to migrate then files are moved as explained by Caulier in #c8 and the database albumroots are updated since digiKam 5 doesn't interpret correctly values like volumeid:?path=%2Fhome%2Fantonio%2FPictures and they need to be url-decoded.
Git commit ca2983d109553c37398da3eafdac9010c7344a9a by Antonio Larrosa. Committed on 03/10/2016 at 16:55. Pushed by antlarr into branch 'master'. Modified NEWS to reference fixed bugs related to migration from digiKam 4 Related: bug 357944, bug 368968 FIXED-IN: 5.3.0 M +4 -1 NEWS http://commits.kde.org/digikam/ca2983d109553c37398da3eafdac9010c7344a9a
Git commit da661e5c84ebaf8037c806a3ac5c004bb6e56d8b by Antonio Larrosa. Committed on 03/10/2016 at 17:05. Pushed by antlarr into branch 'master'. Modified NEWS to reference fixed bugs related to migration from digiKam 4 Related: bug 357944, bug 368968 FIXED-IN: 5.3.0 M +4 -1 NEWS http://commits.kde.org/digikam/da661e5c84ebaf8037c806a3ac5c004bb6e56d8b
I've just migrated from digiKam 4.x to 5.2.0 on an openSUSE Tumbleweed system. There appears to be a problem if 'digikamimagewindowui.rc' is copied during the ~/.kde4/share/apps/digikam/ to ~/.local/share/digikam/ migration. It results in the (digiKam) Image Editor losing from the Main Menu the sub-menu entries for: 'Colour', 'Enhance', 'Decorate', and 'Effects'. Please see this topic on the openSUSE user forum: https://forums.opensuse.org/showthread.php/520361-DigiKam-5-2-0-Image-Editor-missing-a-lot-of-functions
Hello friends!! My name is Hector and I'm from Argentina. First of all, excuse me to reopen the subject .. Years ago I stopped using Digikam because of this problem. Before this, it was my only photo software, I adored it. I had thousands of photos with labels, and various classifications. 2 weeks ago I have updated the system and now I use OpenSuse Tumbleweed. As always I was updating on update, in this opportunity I decided to create a new user since I never open digikam. On this occasion, the user "HAR" (previously called Hector) was created. Now with the HAR user, I was able to open digikam and have created and configured everything from scratch, but I still can not import the Digikam 4 database that has 13.4MB I have read all the comments, but I could not understand how they have been able to solve and if they have managed to import all the previous database to the new version of Digikam. Currently I have installed Digikam v5.9, but I would like to import the previous database to not lose as many years of work as it was mentioned by @Alexey Stukalov How do I use the patch that commented @Simon? Thank you very much for all your opinions and comments. I hope that with your help, I can manage to import my beloved digikam4.db
Hector, This entry do not contains a solutions for you. It's about to import old DK settings using the same account. To use a previous database with a new account, and Database configuration time (see setup database panel), you have a settings where you want to store the sqlite database files. Just point the path where your files are located and DK will ask to use this file or to overwrite. Make database files backup before. Note that DB files must be in R/W for the new account, else it will not work. Gilles Caulier
(In reply to caulier.gilles from comment #29) > Héctor, > > Esta entrada no contiene una solución para usted. Se trata de importar > configuraciones antiguas de DK usando la misma cuenta. > > Para usar una base de datos anterior con una cuenta nueva y el tiempo de > configuración de la base de datos (consulte el panel de configuración de la > base de datos), tiene una configuración donde desea almacenar los archivos > de la base de datos sqlite. Simplemente señale la ruta donde se encuentran > sus archivos y DK le pedirá que use este archivo o que sobrescriba. Hacer > copias de seguridad de archivos de base de datos antes. > > Tenga en cuenta que los archivos DB deben estar en R / W para la nueva > cuenta, de lo contrario no funcionará. > > Gilles Caulier Gracias Gilles. He seguido algunos tips encontrados en otro foro (no recuerdo donde) y he logrado recuperar todas las etiquetas e información de la base de datos anterior. Ahora debo volver a ordenar mi fototeca