Bug 403649 - Filesystem changes are not visible in album view [patch]
Summary: Filesystem changes are not visible in album view [patch]
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Albums-Engine (show other bugs)
Version: 5.6.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-27 09:25 UTC by Lukáš Karas
Modified: 2019-03-15 07:13 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.1.0


Attachments
patch that solves albumRootPath method issue with database root ending with slash (3.65 KB, patch)
2019-02-09 15:11 UTC, Lukáš Karas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lukáš Karas 2019-01-27 09:25:24 UTC
SUMMARY

When I edit image outside digikam and save result to new file (in directory that is DigiKam album), this file is not visible in album. I have to restart digikam.

OBSERVED RESULT

[D] 2019-01-27 10:04:40.309 2054 Digikam::AlbumWatch::rescanDirectory:267 - Detected change, triggering rescan of "/home/karry/data/fotky/2018/12 - prosinec/Drážďany + Míšeň/"
[D] 2019-01-27 10:04:40.548 2054 Digikam::ScanController::slotRelaxedScanning:494 - Starting scan!
[W] 2019-01-27 10:04:40.550 2058 Digikam::CollectionScanner::partialScan:631 - partialScan(QString, QString) called with invalid values
[D] 2019-01-27 10:04:40.697 2054 Digikam::AlbumWatch::rescanDirectory:267 - Detected change, triggering rescan of "/home/karry/data/fotky/2018/12 - prosinec/Drážďany + Míšeň/"
[D] 2019-01-27 10:04:40.959 2054 Digikam::ScanController::slotRelaxedScanning:494 - Starting scan!
[W] 2019-01-27 10:04:40.959 2058 Digikam::CollectionScanner::partialScan:631 - partialScan(QString, QString) called with invalid values


EXPECTED RESULT

It works fine in some previous DigiKam release. But I don't know exact version.

SOFTWARE/OS VERSIONS

Linux: Ubuntu 18.04
KDE Plasma Version: 5.12.7 
KDE Frameworks Version: 5.44.0
Qt Version: 5.9.5
Comment 1 Maik Qualmann 2019-01-27 11:21:52 UTC
The problem can not be reproduced here. Please try a more recent version of digiKam. If no current version is available for your distribution, please try if the problem is still reproducible with the AppImage from https://www.digikam.org/download/.

Maik
Comment 2 caulier.gilles 2019-01-27 17:37:25 UTC
As, Maik said, i just tested with 6.0.0-beta3, and problem is not reproducible here too with this pre-release version...

Gilles Caulier
Comment 3 Lukáš Karas 2019-02-08 07:19:03 UTC
I just upgrade to Ubuntu Cosmic (18.10) that distributes DigiKam in version 5.9.0 and problem is still here.

When I am looking to source (current master), some argument is probably empty:

    if (albumRoot.isNull() || album.isEmpty())
    {
        // If you want to scan the album root, pass "/"
        qCWarning(DIGIKAM_DATABASE_LOG) << "partialScan(QString, QString) called with invalid values";
        return;
    }

How it is possible?

When I run digikam in debugger, it seems that there is no enough debug info, local variables are not visible, just stack trace:

#0  0x00007ffff520bda0 in Digikam::CollectionScanner::partialScan(QString const&, QString const&) () at /usr/lib/digikam/libdigikamdatabase.so.5.9.0
#1  0x00007ffff520c39e in Digikam::CollectionScanner::partialScan(QString const&) () at /usr/lib/digikam/libdigikamdatabase.so.5.9.0
#2  0x00007ffff78c70b8 in Digikam::ScanController::run() () at /usr/lib/digikam/libdigikamgui.so.5.9.0
#3  0x00007ffff5459c87 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ffff3f2f164 in start_thread (arg=<optimized out>) at pthread_create.c:486
        ret = <optimized out>
        pd = <optimized out>
        now = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {140736661997312, -7856654273440063166, 140737488344030, 140737488344031, 140737488344240, 140736661992768, 7856551462427222338, 7856645503036744002}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#5  0x00007ffff4f2bdef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95


...I will try to build digikam with debug symbols...
Comment 4 caulier.gilles 2019-02-08 09:14:37 UTC
With official package, you need to install the _debug_ package to have... debug symbols (:=)))...

Gilles Caulier
Comment 5 Maik Qualmann 2019-02-08 13:07:11 UTC
It's very strange that the AlbumRoot or the Album is null. I do not really have an explanation for that at the moment. The QFileSystemWatcher seems to be send the event, but why the directory being scanned is not valid would actually need to debug. I see in your path special characters, the problem also occurs in folders that contain no special characters? I could not reproduce the problem with your folder name.

Maik
Comment 6 Lukáš Karas 2019-02-09 08:28:46 UTC
I found it. Problem comes from the moment when I replaced my notebook and manually updated drive UUID and path in "AlbumRoots" table. And I keep trailing slash in the path: "/home/karry/data/fotky/". Everything seemed be fine except collection scanning...

When you look carefully to "albumRootPath" method - in current master here: https://cgit.kde.org/digikam.git/tree/core/libs/database/collection/collectionmanager_album.cpp#n93

there is fix for the launchpad bug #221155 that adds slash to the "rootPath" and in my case check if "/root/album" starts with "/root//"...

I was able to fix my mistake with this knowledge and make scanning functional again. Question is if "albumRootPath" should be more robust?  I saw similar pattern on multiple places, I will try to send a patch...
Comment 7 caulier.gilles 2019-02-09 08:40:43 UTC
Thanks Lukas for your investigation.

You are welcome to contribute.

I re-open this file as the problem still open and you will provide a generic patch for this entry.

Best
Gilles Caulier
Comment 8 Maik Qualmann 2019-02-09 09:28:41 UTC
Lukas, look at the implementation of digikam-6.0.0. We now have an easy way to customize the AlbumRoot at drive change. Manual editing of the DB is no longer necessary. It also checks if the AlbumRoot exists and if it does not, it will set the collection unavailable to handle problems with network drives.

Maik
Comment 9 Lukáš Karas 2019-02-09 15:11:06 UTC
Created attachment 117946 [details]
patch that solves albumRootPath method issue with database root ending with slash

I can offer this patch, that solves problem with albumRootPath and deduplicate code little bit. I don't found better place where to put new method, CollectionManager don't sounds like a good place for it :-(

More over, it don't solves original issue - re-scan is started properly, but view is not updated. It seems that more places in the code don't work with album root that is ending with slash...
Comment 10 caulier.gilles 2019-02-09 15:20:16 UTC
As 6.0.0 will be released tomorrow, this patch is targeted to 6.1.0

Gilles
Comment 11 Maik Qualmann 2019-03-14 20:09:03 UTC
Git commit df26831e562625cd8ba731c11f35a6279945a13b by Maik Qualmann.
Committed on 14/03/2019 at 20:08.
Pushed by mqualmann into branch 'master'.

check a slash from the end of the album root path
FIXED-IN: 6.1.0

M  +2    -1    NEWS
M  +9    -1    core/libs/database/collection/collectionmanager_p.h

https://commits.kde.org/digikam/df26831e562625cd8ba731c11f35a6279945a13b
Comment 12 Maik Qualmann 2019-03-14 20:13:02 UTC
I chose another variant of the patch. We should make sure that the function everywhere gives us a correct location root path. Otherwise this check would have to be repeated again and again.

Maik
Comment 13 Lukáš Karas 2019-03-15 07:13:20 UTC
Thank you. Please consider to add some "isFileNested" variant anyway. Around collection is a lot of duplicate code that can be moved to utility methods...