Bug 361339 - Creates nameless subalbums and corrupts album hierarchy
Summary: Creates nameless subalbums and corrupts album hierarchy
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Albums (show other bugs)
Version: 5.0.0
Platform: Compiled Sources Linux
: NOR major
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-03 11:46 UTC by kramski
Modified: 2017-07-19 13:58 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.0.0


Attachments
Screenshot 1: Healthy album before import (54.06 KB, image/png)
2016-04-03 11:48 UTC, kramski
Details
Screenshot 2: Import Window (539.47 KB, image/png)
2016-04-03 11:49 UTC, kramski
Details
Screenshot 3: Album after import (164.83 KB, image/png)
2016-04-03 11:50 UTC, kramski
Details
Console output of digikam showing two testcases (196.47 KB, text/x-log)
2016-04-03 12:20 UTC, kramski
Details
testDebug.patch (1.29 KB, patch)
2016-04-04 17:19 UTC, Maik Qualmann
Details
Console output of small testcase with debug patch enabled (18.30 KB, text/x-log)
2016-04-04 20:40 UTC, kramski
Details
mkdirTest.patch (1.03 KB, patch)
2016-04-05 18:49 UTC, Maik Qualmann
Details
Console output after mkdirTest.patch (17.56 KB, text/x-log)
2016-04-05 20:36 UTC, kramski
Details
test2Debug.patch (1.40 KB, patch)
2016-04-05 21:06 UTC, Maik Qualmann
Details
CoreDBUrl.patch (1.12 KB, patch)
2016-04-06 16:32 UTC, Maik Qualmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kramski 2016-04-03 11:46:58 UTC
I'm running 5.0.0beta5 (digikam-git r33955.9e7223e-1 from AUR) on Arch with a MySQL backend.

Besides the wanted, correct date-based albums, importing new pictures with "Auto-creation of albums" creates additional, nameless sub albums which seem to contain duplicate pictures.

These "ghost albums" seem to have the same effective filesystem path as the correct ones, so deleting them deletes the wanted subalbums and pictures as well.

Opening such an album in filemanger reveals empty trailing path components, e.g.: "/mnt/nas/sandl/bilder/Fotos/Maxi-Test/2016///".

My albums reside on NFS, but the problem exists for local collections as well. It is also independent of the camera used and of the actual date format (can also be reproduced with the default ISO format).

As a workaround: How can I get rid of subalbums in the folder pane without deleting the pictures as well? (Sorry if that's FAQ, I'm quite new to Digikam).

Reproducible: Always

Steps to Reproduce:
1. Create a collection from some existing folder hierarchy (see screenshot 1)
2. Import some new picture which will autocreate new date based subalbums (see screenshot 2)


Actual Results:  
Additional, nameless subalbums will be created (see screenshot 3)

Expected Results:  
Only the wanted, date based subalbums should be created.
Comment 1 kramski 2016-04-03 11:48:43 UTC
Created attachment 98212 [details]
Screenshot 1: Healthy album before import
Comment 2 kramski 2016-04-03 11:49:36 UTC
Created attachment 98213 [details]
Screenshot 2: Import Window
Comment 3 kramski 2016-04-03 11:50:41 UTC
Created attachment 98214 [details]
Screenshot 3: Album after import
Comment 4 kramski 2016-04-03 12:20:59 UTC
Created attachment 98215 [details]
Console output of digikam showing two testcases
Comment 5 Maik Qualmann 2016-04-03 19:34:42 UTC
I can not reproduce this problem here (tested with SQLite and internal MySQL DB). I see no problem in this source code. The same problem, If you manually create a album (right-click album tree -> New...)? Can you test it with completely locally album and a SQLite DB?

Maik
Comment 6 kramski 2016-04-03 20:38:59 UTC
Thanks Maik, with your help I was able to find a much simpler testcase.

I can reproduce this with SQLite and a local album and even if I just manually create a new album with right-click, so this is not really an import issue.

However, this seems to require a particular folder structure. To reproduce:

1. Create a file system folder named "Test-local3". Inside "Test-local3" create an empty folder named "Folder". Inside "Folder" create a folder named "Subfolder" and put an image there.

2. Create a new Digikam album for "Test-local3" with "Settings / Digikam einrichten (configure?) / Collections / Add [local] Collection"

3. Right-click on "Folder" and create a new album "NewSubfolder".

4. See a nameless album and duplicate albums appear...
Comment 7 Maik Qualmann 2016-04-04 06:08:51 UTC
Also with this test case is not to reproduce the problem here. There must be another cause. In principle, it is impossible that digiKam folder with slashes created at the end.
Could you try a patch? I would insert more debug messages.

Maik
Comment 8 kramski 2016-04-04 08:45:42 UTC
Ok, sure.
Comment 9 Maik Qualmann 2016-04-04 17:19:16 UTC
Created attachment 98247 [details]
testDebug.patch

Please try this patch, create a wrong album folder and upload the console output.

In the "core" folder:
patch -p0 < testDebug.patch

Maik
Comment 10 kramski 2016-04-04 20:40:09 UTC
Created attachment 98248 [details]
Console output of small testcase with debug patch enabled

Thanks. Here is the requested log of a small testcase (new album via right click), reproduced on a different (but very similar) machine. 

Heinz
Comment 11 Maik Qualmann 2016-04-05 18:49:48 UTC
Created attachment 98257 [details]
mkdirTest.patch

This is not a productive patch, it is only a test. Please look whether the issue is resolved.

Maik
Comment 12 kramski 2016-04-05 20:36:58 UTC
Created attachment 98261 [details]
Console output after mkdirTest.patch

Sorry, no progress. issue still exists.

Heinz
Comment 13 Maik Qualmann 2016-04-05 21:06:32 UTC
Created attachment 98262 [details]
test2Debug.patch

Strange problem, please give me the ouput from this patch. What for a  file system you use?

Maik
Comment 14 kramski 2016-04-05 21:34:06 UTC
I'm setting up a new family picture server via NFS V3, server is BTRFS. This used to work approx. 4 weeks ago, don't know which update broke it.

Latests tests were done on a laptop on ext4 (DB and picture folders). Can also reproduce on XFS and on Samba mounts, so I don't think it's FS related.

Latest output:

[...]
digikam.general: Cancel Main Thread
digikam.general: One job is done
digikam.geoiface: ----
------------------------>AlbumManager::createPAlbum--1--> "New Album"
------------------------>AlbumManager::createPAlbum--2--> (".", "..", "Folder")
------------------------>AlbumManager::createPAlbum--3--> QUrl("file:///mufu/transfer/test-local5/Folder/New Album")
digikam.general: QFileSystemWatcher detected change at "/mufu/transfer/test-local5/Folder//"
digikam.general: Detected change, triggering rescan of directory "/mufu/transfer/test-local5/Folder//"
------------------------>AlbumManager::createPAlbum--4--> (".", "..", "Folder")
digikam.database: Starting scan!
digikam.dimg: "/mufu/transfer/test-local5/Folder//Subfolder/user-manager.png"  : PNG file identified
digikam.database: Adding new item "/mufu/transfer/test-local5/Folder//Subfolder/user-manager.png"
digikam.database: Recognized "/mufu/transfer/test-local5/Folder//Subfolder/user-manager.png" as identical to item 11
digikam.database: Scanning took 1 ms
digikam.database: Finishing took 5 ms
digikam.geoiface: ----
digikam.general: Cancel Main Thread
[...]
 
Heinz (afk for today)
Comment 15 Maik Qualmann 2016-04-06 16:32:56 UTC
Created attachment 98268 [details]
CoreDBUrl.patch

Please try this patch for testing. What Qt version you use?

Maik
Comment 16 kramski 2016-04-06 18:11:09 UTC
Great, that fixed it! Thanks a lot for your help! 
Versions: KDE Frameworks 5.20.0, Qt 5.6.0, kernel 4.4.5-1-ARCH x86_64
Output:
[...]
digikam.geoiface: ----
------------------------>AlbumManager::createPAlbum--1--> "New Album"
digikam.coredb: CoreDbUrl::fromAlbumAndName :  "digikamalbums:/Folder/?albumRoot=/mufu/transfer/test-local5&albumRootId=1&databaseType=QSQLITE&databaseNameCore=/mufu/transfer/digikam/digikam4.db&databaseNameThumbnails=/mufu/transfer/digikam/thumbnails-digikam.db&databaseNameFace=/mufu/transfer/digikam/recognition.db&connectOptions=&hostName=&userName=&password="
------------------------>AlbumManager::createPAlbum--2--> (".", "..", "Folder")
------------------------>AlbumManager::createPAlbum--3--> QUrl("file:///mufu/transfer/test-local5/Folder/New Album")
digikam.general: QFileSystemWatcher detected change at "/mufu/transfer/test-local5/Folder/"
digikam.general: Detected change, triggering rescan of directory "/mufu/transfer/test-local5/Folder/"
------------------------>AlbumManager::createPAlbum--4--> (".", "..", "Folder")
digikam.coredb: CoreDbUrl::fromAlbumAndName :  "digikamalbums:/Folder/New Album/?albumRoot=/mufu/transfer/test-local5&albumRootId=1&databaseType=QSQLITE&databaseNameCore=/mufu/transfer/digikam/digikam4.db&databaseNameThumbnails=/mufu/transfer/digikam/thumbnails-digikam.db&databaseNameFace=/mufu/transfer/digikam/recognition.db&connectOptions=&hostName=&userName=&password="
digikam.database: Starting scan!
digikam.geoiface: ----
digikam.geoiface: ----
digikam.coredb: CoreDbUrl::fromAlbumAndName :  "digikamalbums:/Folder/New Album/?albumRoot=/mufu/transfer/test-local5&albumRootId=1&databaseType=QSQLITE&databaseNameCore=/mufu/transfer/digikam/digikam4.db&databaseNameThumbnails=/mufu/transfer/digikam/thumbnails-digikam.db&databaseNameFace=/mufu/transfer/digikam/recognition.db&connectOptions=&hostName=&userName=&password="
digikam.general: Using  4  CPU core to run threads
[...]

Should I adjust bug title and component to better reflect the facts?

Thanks again and regards,
   Heinz
Comment 17 Maik Qualmann 2016-04-06 19:40:51 UTC
Git commit 13f08a6e19808cdb047511322c533e1d3a706ff2 by Maik Qualmann.
Committed on 06/04/2016 at 19:39.
Pushed by mqualmann into branch 'master'.

fix double slashes in QUrl with Qt-5.6.0
FIXED-IN: 5.0.0

M  +2    -1    NEWS
M  +1    -4    libs/database/coredb/coredburl.cpp

http://commits.kde.org/digikam/13f08a6e19808cdb047511322c533e1d3a706ff2
Comment 18 Maik Qualmann 2016-04-06 19:44:01 UTC
Thank you for testing the patches.

Maik
Comment 19 Maik Qualmann 2016-04-29 20:34:07 UTC
*** Bug 362268 has been marked as a duplicate of this bug. ***