[digikam] [Bug 318902] New: very long lasting search for new items after copy of sqlite3 database

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 318902] New: very long lasting search for new items after copy of sqlite3 database

krienke
https://bugs.kde.org/show_bug.cgi?id=318902

            Bug ID: 318902
           Summary: very long lasting search for new items after copy of
                    sqlite3 database
    Classification: Unclassified
           Product: digikam
           Version: 3.1.0
          Platform: openSUSE RPMs
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: [hidden email]
          Reporter: [hidden email]

I have two linux (opensuse12.3, KDE 4.10.2) systems. On both systems I sync all
of my photos (rsync) as well as digikams database. I use the same version of
digikam on both systems at the moment 3.1.0.  The photos are stored in exactly
the same path on both systems.

In order to get this working I inserted a special entry a long time ago in
digikams database in table AlbumRoots:

sqlite> select * from AlbumRoots;
id|label|status|type|identifier|specificPath
1|photos|0|1|volumeid:?path=/home/krienke/lib/photos|/

/home/krienke/lib/photos is the Albumroot on both systems. The only difference
is that on one system its a directory on the second its a symbolic link.
However this did not change in the past 5 years and this setup used to work
really fine.  

Since about version 3.0 I have a strange problem on the sync destination .
After I have synced say from system A to system B and then start digikam on
system B digikam searches for new entries as usual. But the unusual thing is
that this search takes at least 30minutes on a 4 core Core-i5 with 8GB RAM and
about 2000 photos. The disk is very busy in this time. It only takes such a
long time after a sync process else the search for new entries is done after a
few seconds.

The search for new entries is actually not needed at all in this case because
everything is in sync because rsync creates an exact copy.

Reproducible: Always

Steps to Reproduce:
1. Rsync all photos and databse from one to another system
2. start digikam on the destination system
3.
Actual Results:  
digikam takes a very long time searching for new items

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 318902] very long lasting search for new items after copy of sqlite3 database

Gilles Caulier-4
https://bugs.kde.org/show_bug.cgi?id=318902

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]
          Component|general                     |Searches

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 318902] very long lasting search for new items after copy of sqlite3 database

Marcel Wiesweg
In reply to this post by krienke
https://bugs.kde.org/show_bug.cgi?id=318902

--- Comment #1 from Marcel Wiesweg <[hidden email]> ---
Does a sync update the modification time in the file system?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 318902] very long lasting search for new items after copy of sqlite3 database

krienke
In reply to this post by krienke
https://bugs.kde.org/show_bug.cgi?id=318902

--- Comment #2 from [hidden email] ---
Just tested what files are modified by the sync (ls -lR). It is as it should
be, only the files that really changed on the source side as well as the parent
directory show a change in mtime on the destination side as well as the digikam
database file. All other files and directories remain untouched.

After the sync I started an strace  -v -f -F -e 'trace=open' on the digikam
process that again started a long lasting search for new entries. I could see
that each and every photo is beeing opened not only the modified ones or those
in a directory with a changed mtime.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 318902] very long lasting search for new items after copy of sqlite3 database

krienke
In reply to this post by krienke
https://bugs.kde.org/show_bug.cgi?id=318902

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from [hidden email] ---
I checked again and my problem is related to mtime.

In my first test I tested only what changes on  the destination side when I run
a sync from source to destination. This was ok. However I now compared the
modification time of the files on source and destination and there were many
files that were not identically.

After fixing this sync problem, after a sync digikam still looks for new files
on the destination but much faster (about 15sec) which is ok.

Thanks for the mtime-hint
Rainer

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 318902] very long lasting search for new items after copy of sqlite3 database

Gilles Caulier-4
In reply to this post by krienke
https://bugs.kde.org/show_bug.cgi?id=318902

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Version Fixed In|                            |3.2.0

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel