[digiKam-users] Network Library too slow and not reconnect

Thu Apr 23 21:42:55 BST 2020

Hi Martin,

 My MBP is from late 2011. And now I am finding out this problem. It always worked pretty good.

 It's hardware is excellent even for a 9 years old notebook. I got surprised that the ether port is algo Gb, never worried about it's specifications.

 Cannot have a local copy of my library, it has 800gb at least, and I already have it as a Mac Photos library. So I would have at least 1.6tb of local data.

 Continuing my tests, I opened digikam, unchecked to watch for new itens and restarted. The interface opened quickly, but I think the main reason is that the DB is still empty. The second time I opened, I did it via terminal, and got the message:

 Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!

 Searched about it and got it work installing ports for MAC and then starting dbus mannually (need to see if it will auto load on restart). 

 After that, started digikam again and did not get the message, only those QFSFileEngine:

./digikam 

QCommandLineParser: already having an option named "h"

QCommandLineParser: already having an option named "help-all"

QCommandLineParser: already having an option named "v"

qt.qpa.fonts: Populating font family aliases took 712 ms. Replace uses of missing font family ".SF NS Text" with one that exists to avoid this cost.

KMemoryInfo: Platform identified :  "Unknown"

KMemoryInfo: TotalRam:  -1

QtAV 1.13.0(Apr  3 2020, 05:59:02)

Multimedia framework base on Qt and FFmpeg.

Distributed under the terms of LGPLv2.1 or later.

Donate: http://qtav.org/donate.html

Source: https://github.com/wang-bin/QtAV

Home page: http://qtav.org

QFSFileEngine::open: No file name specified

kf5.kxmlgui: Unhandled container to remove :  Digikam::DigikamApp

QFSFileEngine::open: No file name specified

QFSFileEngine::open: No file name specified

QFSFileEngine::open: No file name specified

QFSFileEngine::open: No file name specified

QFSFileEngine::open: No file name specified

QFSFileEngine::open: No file name specified

HEVC encoder max bit depth: 8

HEVC encoder max bits depth: 8

Now it's running, started scanning my library and it's not slow, but also not fast, about 5 photos per second. it's in 2% now. 

I'll let it running all night (and day)... then will test with the new settings and database to see if it's acceptable.

Regards.

---- Ativado Qui, 23 abr 2020 04:37:10 -0300 Martin Althoff <martin.althoff at mail.de> escreveu ----

Let me chip in my two cents worth as a long term MacBookPro owner (current one 5 years 
old, running 10.14.6), though I have no solution to offer. 

For a long time (couple of years, various versions of OSX/MacOS) I was permanently 
struggling with poor network performance. Wifi was worse then cable based. Ping values 
were fine. I was only looking within my GB home network. Occasionally by factor 2 or 3 
below Windows/Linux. Searching around I saw others have the same problem, followed tips 
(disable anything on the Mac that's in the network path: firewalls etc), without much 
achieved. Best answer I found: OSX/MacOS has a problematic network handling. Just as NFS 
is poor. All not a focus of Apple. This is why I guess you are looking at more of an Apple 
then DK problem. 

With Mojave (10.14) things subjectively got a bit better, though I have kind of given up 
on it. Copying a 5GB file to an NFS connected share through WiFi now actually works, 
before (from when I don't know) it usually didn't (speed and disconnects).  Most of my 
work takes place on Linux by now. New hassles, but others are gone. 

Just a thought: How about keeping two synchronized copies of your images? 300G is not so 
much. Digikam works on a local copy. Obviously the remote copy has to be the absolute 
master copy if that is needed. 

Martin 

On Wed, 2020-04-22 at 21:58 -0300, Alex - Família Turista wrote: 
> I’ll do that. Have done before, it’s very easy. 
> I just have to have some time. 
> 
> Yesterday I decided to empty my DK database and config and start from zero. 
> 
> On the initial config screen I setup my collection and I’d started scanning. It was quite fast. A small dialog showing the path currently being scanned. Took about 3 hours max (over Wi-Fi).  I thought the problem was fixed but after this initial scam, the interface was shown and the process of finding new items started from 0% and seemed frozen again. 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20200423/bf75221b/attachment.html>