Bug 357944 - wrong encoded collection paths after upgrade from digikam v4.x
Summary: wrong encoded collection paths after upgrade from digikam v4.x
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Setup-Database (show other bugs)
Version: 5.1.0
Platform: Other Linux
: NOR minor
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-13 18:06 UTC by Thomas Eschenbacher
Modified: 2016-10-23 09:43 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.3.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Eschenbacher 2016-01-13 18:06:49 UTC
This seems to be an issue when coming from an older installation, digikam-4.x:

Reproducible: Always

Steps to Reproduce:
1. take a system with an old digikam-4 configuration
2. make sure you don't have a ~/.config/digikamrc
3. start digikam v5
4. in the wizard, when asked for location of your collection, enter some path
5. enter the settings dialog and look at the list of local collections

Actual Results:  
The location I entered in the wizard is shown correctly.

But the locations of the local collections that I have used for digikam-4 all are encoded, as for example "%2Fhome%2Fuser%2FPictures".

Expected Results:  
The paths of the old installation should be migrated, with proper encoding.

This seems to be relevant only when migrating, when I add the locations manually again and remove the wrong encoded ones it stays ok (no toggle effect, settings stay as they are).
Comment 1 caulier.gilles 2016-06-30 12:52:20 UTC
This problem still reproducible with digiKam 5.0.0-beta7 ?

Gilles Caulier
Comment 2 Thomas Eschenbacher 2016-06-30 16:25:13 UTC
I'm sorry, but I don't have enough time to prepare an environment to reproduce and test it. Additionally my collection already is converted and I don't have an old digikam-4 at hand.
Comment 3 caulier.gilles 2016-07-01 21:09:47 UTC
I can confirm  that 5.0.0-beta7 has this problem....

Gilles Caulier
Comment 4 Maik Qualmann 2016-07-02 20:50:26 UTC
Git commit 059742556c055d31d95ba45b741a6006f93e9ba0 by Maik Qualmann.
Committed on 02/07/2016 at 20:49.
Pushed by mqualmann into branch 'master'.

fix empty or wrong collection label

M  +2    -1    libs/album/albummanager.cpp
M  +2    -1    libs/database/coredb/coredbschemaupdater.cpp

http://commits.kde.org/digikam/059742556c055d31d95ba45b741a6006f93e9ba0
Comment 5 Maik Qualmann 2016-07-02 20:51:55 UTC
Gilles,

Can you test the commit whether the bug is fixed?

Maik
Comment 6 caulier.gilles 2016-07-02 20:55:29 UTC
I tested under OSX. It work better now...

Gilles
Comment 7 Simon 2016-08-17 22:13:56 UTC
This is is still a problem in 5.1.0. See following bug report to debian:

Package: digikam
Version: 4:5.1.0-2
Severity: important
Tags: patch

--- Please enter the report below this line. ---
Just upgraded from latest Debian Digikam version 4 (with database version 6). 
I set the path of my old database on first start and when Digikam opened there 
where no more albums in the interface.

After restoration of my old database and various tests, I discover that my 
album root path where "urlencoded" in previous version with all '/' replace by 
'%2F'. Whit such path, Digikam 5.1 does not recognize album root and remove 
all metadata from the database on albums refreshing.

To correct this, I had to edit with sqlitebrowser the file digikam4.db and in 
the table AlbumRoots, replace all occurence of '%2F' bay '/' in the field 
identifier. Then Digikam recognize the path an show all my albums, photo and 
associated metadata.

--- System information. ---
Architecture: amd64
Kernel:       Linux 4.6.0-1-amd64

Debian Release: stretch/sid
  500 unstable        http.debian.net 
  500 testing         http.debian.net 
  500 syncthing       apt.syncthing.net 
  500 stable          security.debian.org 
  500 stable          http.debian.net 
  101 experimental    http.debian.net 

--- Package information. ---
Depends                        (Version) | Installed
========================================-+-================
digikam-private-libs       (= 4:5.1.0-2) | 4:5.1.0-2
libc6                          (>= 2.14) | 
libgcc1                       (>= 1:3.0) | 
libkf5configcore5            (>= 4.97.0) | 
libkf5coreaddons5           (>= 4.100.0) | 
libkf5filemetadata3         (>= 5.1.0.1) | 
libkf5i18n5                  (>= 4.97.0) | 
libkf5xmlgui5                (>= 4.96.0) | 
libqt5core5a             (>= 5.6.0~beta) | 
libqt5gui5                    (>= 5.4.0) | 
libqt5sql5                    (>= 5.4.0) | 
libqt5widgets5                (>= 5.4.0) | 
libstdc++6                      (>= 4.9) | 
perl:any                                 | 
libqt5sql5-sqlite                        | 
digikam-data               (= 4:5.1.0-2) | 


Recommends         (Version) | Installed
============================-+-===========
www-browser                  | 
ffmpegthumbs                 | 4:16.04.2-1
 OR mplayerthumbs            | 4:15.08.3-2


Suggests            (Version) | Installed
=============================-+-===========
digikam-doc                   | 4:5.1.0-2
systemsettings                | 4:5.7.0-1
Comment 8 Antonio Larrosa 2016-10-03 17:06:04 UTC
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 364258, bug 368968
FIXED-IN: 5.3.0

M  +4    -1    NEWS

http://commits.kde.org/digikam/ca2983d109553c37398da3eafdac9010c7344a9a
Comment 9 Antonio Larrosa 2016-10-03 17:26:50 UTC
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 364258, bug 368968
FIXED-IN: 5.3.0

M  +4    -1    NEWS

http://commits.kde.org/digikam/da661e5c84ebaf8037c806a3ac5c004bb6e56d8b
Comment 10 Simon 2016-10-23 09:43:01 UTC
Hi Antonio

Thanks for working on this.
I do not see how this addresses the issue of encoded paths ("%2F" instead of "/") in the database, are you sure this is fixed with your changes?