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

[Alex Antão]

Hi all,

  I have a NAS which stores all my photos. Configured digikam to it in the Network Drive category.

  My connection is not Slow, My network is all 1 Gigabit and my current wifi connection is about 450Mbps 

  Digikam takes about half an hour to load. When it loads, it stays on searching for new items for a long, long time. Running on macOS Catalina.

 

  I think it should be a lot faster than that.

  Also, if the network drive is disconnect at some point, or I start Digikam with network drive not mounted, Digikam starts really fast, only showing the items of the library but not making any changes to the real files. If I reconnect the drive, Digikam does not recognise it and continue working "off-line".

Whay do I have an option to catalog a Library as a network drive if it does not have any changes as a normal and local library ????

   Is it a bug ? Is there a way to workaround ?

Thanks..

 

[Maik Qualmann]

Which digiKam version do you use exactly?
Please test with the current digiKam-7.0.0-Beta3 whether the long start can
still be reproduced:

https://files.kde.org/digikam/

Maik

Am Dienstag, 7. April 2020, 00:14:46 CEST schrieb Alex Antão:

> Hi all,
>
>
>
>   I have a NAS which stores all my photos. Configured digikam to it in the
> Network Drive category.
>
>
>
>   My connection is not Slow, My network is all 1 Gigabit and my current wifi
> connection is about 450Mbps
>
>
>
>   Digikam takes about half an hour to load. When it loads, it stays on
> searching for new items for a long, long time. Running on macOS Catalina.
>
>  
>
>   I think it should be a lot faster than that.
>
>
>
>   Also, if the network drive is disconnect at some point, or I start Digikam
> with network drive not mounted, Digikam starts really fast, only showing
> the items of the library but not making any changes to the real files. If I
> reconnect the drive, Digikam does not recognise it and continue working
> "off-line".
>
> Whay do I have an option to catalog a Library as a network drive if it does
> not have any changes as a normal and local library ????
>
>
>
>    Is it a bug ? Is there a way to workaround ?
>
>
>
> Thanks..
>  

[Alex Antão]

I use 6.4.0 . Is 7.0 beta stable and reliable enouth to use ?

My library is huge, more than 100.000 photos and more than 800Gb.

I just don't want to change and being not able to use it at all, or lost some photos...

Thanks

---- Ativado Ter, 07 abr 2020 02:58:19 -0300 Maik Qualmann <[hidden email]> escreveu ----

Which digiKam version do you use exactly?
Please test with the current digiKam-7.0.0-Beta3 whether the long start can
still be reproduced:

https://files.kde.org/digikam/

Maik

Am Dienstag, 7. April 2020, 00:14:46 CEST schrieb Alex Antão:

> Hi all,
>
>
>
> I have a NAS which stores all my photos. Configured digikam to it in the
> Network Drive category.
>
>
>
> My connection is not Slow, My network is all 1 Gigabit and my current wifi
> connection is about 450Mbps
>
>
>
> Digikam takes about half an hour to load. When it loads, it stays on
> searching for new items for a long, long time. Running on macOS Catalina.
>
>
>
> I think it should be a lot faster than that.
>
>
>
> Also, if the network drive is disconnect at some point, or I start Digikam
> with network drive not mounted, Digikam starts really fast, only showing
> the items of the library but not making any changes to the real files. If I
> reconnect the drive, Digikam does not recognise it and continue working
> "off-line".
>
> Whay do I have an option to catalog a Library as a network drive if it does
> not have any changes as a normal and local library ????
>
>
>
> Is it a bug ? Is there a way to workaround ?
>
>
>
> Thanks..
>

[woenx]

Alex, what is the typical network latency (the milliseconds on each ping) to
the server where the photos are stored?

I spend some time abroad last year and the latency was quite high (~125ms)
despite having a decent network speed (realistically, ~40Mbps). My library
(around 100000 pictures, around 300GB), and digikam took around 9 minutes
just to show the main interface (and many many more to complete the initial
scan). However, the same library, from home (40ms to the server where they
are stored), starts almost immediately and completes the initial scan within
7 minutes, considering there are not new pictures to be found. So,
apparently, network latency matters even more than network speed. I also use
a newer version, so it might have been caused by some bug that is fixed now.

In the case there are new pictures to be found, digikam tried to transfer
them in order to look at the metadata, so the process is slower, but that is
a background process and you can use the program normally meanwhile.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Alex Antão]

Hi, woenx,

   Sorry by the huge delay. Let me explain all I have been passing through.

   After you said about ping time (why I didn't think about testing this? thinking the most complex tests and forgot the basic..) I tested here and almost had a crash. Ping times between 2.000ms and 5.000ms ! OMG...

64 bytes from 192.168.88.2: icmp_seq=21 ttl=64 time=4.874 ms

64 bytes from 192.168.88.2: icmp_seq=22 ttl=64 time=2.195 ms

64 bytes from 192.168.88.2: icmp_seq=23 ttl=64 time=4.000 ms

64 bytes from 192.168.88.2: icmp_seq=24 ttl=64 time=3.837 ms

64 bytes from 192.168.88.2: icmp_seq=25 ttl=64 time=2.055 ms

64 bytes from 192.168.88.2: icmp_seq=26 ttl=64 time=5.138 ms

64 bytes from 192.168.88.2: icmp_seq=27 ttl=64 time=4.982 ms

64 bytes from 192.168.88.2: icmp_seq=28 ttl=64 time=2.447 ms

64 bytes from 192.168.88.2: icmp_seq=29 ttl=64 time=5.028 ms

64 bytes from 192.168.88.2: icmp_seq=30 ttl=64 time=5.927 ms

64 bytes from 192.168.88.2: icmp_seq=31 ttl=64 time=80.328 ms

64 bytes from 192.168.88.2: icmp_seq=32 ttl=64 time=1.990 ms

64 bytes from 192.168.88.2: icmp_seq=33 ttl=64 time=200.179 ms

64 bytes from 192.168.88.2: icmp_seq=34 ttl=64 time=5.035 ms

64 bytes from 192.168.88.2: icmp_seq=35 ttl=64 time=1.418 ms

64 bytes from 192.168.88.2: icmp_seq=36 ttl=64 time=2.272 ms

64 bytes from 192.168.88.2: icmp_seq=37 ttl=64 time=4.538 ms

64 bytes from 192.168.88.2: icmp_seq=38 ttl=64 time=1.910 ms

64 bytes from 192.168.88.2: icmp_seq=39 ttl=64 time=2.205 ms

64 bytes from 192.168.88.2: icmp_seq=40 ttl=64 time=4.593 ms

Initially, I thought it was my NAS problem, but after some tests I realized that the high ping was from my MacBook and  my AP (an Tp-Link RE450).

Since I was about to chang it, I left as it was.

Some days later, I had changed all my AP do TP-Link Deco M5. All of them connected by 1Gb cable to my router.

But the ping times were still very high. The Wi-Fi connection on my MBP was telling my speed was 300Mbps, a little lower than the 450Mbps of RE450,

but then I was thinking that my Wifi card (802.11/n) could never reach the 450mbps. don't know why it was on RE450.

But nothing changed on my ping time. So I started searching about high pings on MacBook Pro, and realized that everybody was having issues on these computers regarding to Wifi. I tried a lot of solutions, took me some days to try all, but nothing worked.

I then tried to run some other tests. I opened my wife's computer, a newly bought Samsung with Windows 10, connected wifi Wifi/ac and ping my router:

Disparando 192.168.88.2 com 32 bytes de dados:

Resposta de 192.168.88.2: bytes=32 tempo=3ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=7ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=4ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=5ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=4ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=6ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=4ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=6ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=7ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=6ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=4ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=3ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=8ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=3ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=7ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=5ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=4ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=3ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=6ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=4ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=7ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=3ms TTL=64

Windows's ping is different. I does not show decimal numbers, and I don't know if my MBP's numbers (ex.: time=3.837 ms) are 3ms or 3837ms.

Here in Brazil we use the comma as decimal separator, but I think my MBP is giving me decimal separated by dots. So, the times are equivalent.

Put the Samsung on cable (Gb ethernet) and ping again:

Disparando 192.168.88.2 com 32 bytes de dados:

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo<1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo<1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo<1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo<1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo<1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Resposta de 192.168.88.2: bytes=32 tempo=1ms TTL=64

Put my MBP on the same cabe (also Gb ethernet):

64 bytes from 192.168.88.2: icmp_seq=136 ttl=64 time=1.308 ms

64 bytes from 192.168.88.2: icmp_seq=137 ttl=64 time=0.821 ms

64 bytes from 192.168.88.2: icmp_seq=138 ttl=64 time=1.289 ms

64 bytes from 192.168.88.2: icmp_seq=139 ttl=64 time=1.185 ms

64 bytes from 192.168.88.2: icmp_seq=140 ttl=64 time=1.123 ms

64 bytes from 192.168.88.2: icmp_seq=141 ttl=64 time=1.239 ms

64 bytes from 192.168.88.2: icmp_seq=142 ttl=64 time=1.222 ms

64 bytes from 192.168.88.2: icmp_seq=143 ttl=64 time=0.872 ms

64 bytes from 192.168.88.2: icmp_seq=144 ttl=64 time=1.324 ms

64 bytes from 192.168.88.2: icmp_seq=145 ttl=64 time=1.219 ms

64 bytes from 192.168.88.2: icmp_seq=146 ttl=64 time=1.095 ms

64 bytes from 192.168.88.2: icmp_seq=147 ttl=64 time=0.826 ms

64 bytes from 192.168.88.2: icmp_seq=148 ttl=64 time=1.020 ms

64 bytes from 192.168.88.2: icmp_seq=149 ttl=64 time=0.949 ms

64 bytes from 192.168.88.2: icmp_seq=150 ttl=64 time=0.991 ms

64 bytes from 192.168.88.2: icmp_seq=151 ttl=64 time=1.221 ms

64 bytes from 192.168.88.2: icmp_seq=152 ttl=64 time=1.270 ms

64 bytes from 192.168.88.2: icmp_seq=153 ttl=64 time=0.922 ms

64 bytes from 192.168.88.2: icmp_seq=154 ttl=64 time=0.774 ms

64 bytes from 192.168.88.2: icmp_seq=155 ttl=64 time=0.871 ms

64 bytes from 192.168.88.2: icmp_seq=156 ttl=64 time=0.769 ms

64 bytes from 192.168.88.2: icmp_seq=157 ttl=64 time=0.731 ms

64 bytes from 192.168.88.2: icmp_seq=158 ttl=64 time=0.731 ms

64 bytes from 192.168.88.2: icmp_seq=159 ttl=64 time=0.774 ms

64 bytes from 192.168.88.2: icmp_seq=3505 ttl=64 time=1.075 ms

64 bytes from 192.168.88.2: icmp_seq=3506 ttl=64 time=1.226 ms

64 bytes from 192.168.88.2: icmp_seq=3507 ttl=64 time=1.366 ms

64 bytes from 192.168.88.2: icmp_seq=3508 ttl=64 time=1.091 ms

64 bytes from 192.168.88.2: icmp_seq=3509 ttl=64 time=1.217 ms

64 bytes from 192.168.88.2: icmp_seq=3510 ttl=64 time=1.130 ms

64 bytes from 192.168.88.2: icmp_seq=3511 ttl=64 time=1.188 ms

64 bytes from 192.168.88.2: icmp_seq=3512 ttl=64 time=0.775 ms

64 bytes from 192.168.88.2: icmp_seq=3513 ttl=64 time=0.936 ms

64 bytes from 192.168.88.2: icmp_seq=3514 ttl=64 time=0.799 ms

64 bytes from 192.168.88.2: icmp_seq=3515 ttl=64 time=0.609 ms

64 bytes from 192.168.88.2: icmp_seq=3516 ttl=64 time=0.610 ms

64 bytes from 192.168.88.2: icmp_seq=3517 ttl=64 time=0.756 ms

64 bytes from 192.168.88.2: icmp_seq=3518 ttl=64 time=0.997 ms

64 bytes from 192.168.88.2: icmp_seq=3519 ttl=64 time=0.744 ms

64 bytes from 192.168.88.2: icmp_seq=3520 ttl=64 time=1.046 ms

64 bytes from 192.168.88.2: icmp_seq=3521 ttl=64 time=0.753 ms

64 bytes from 192.168.88.2: icmp_seq=3522 ttl=64 time=0.628 ms

64 bytes from 192.168.88.2: icmp_seq=3523 ttl=64 time=1.025 ms

64 bytes from 192.168.88.2: icmp_seq=3524 ttl=64 time=1.389 ms

64 bytes from 192.168.88.2: icmp_seq=3525 ttl=64 time=0.775 ms

64 bytes from 192.168.88.2: icmp_seq=3526 ttl=64 time=0.661 ms

64 bytes from 192.168.88.2: icmp_seq=3527 ttl=64 time=0.991 ms

I think the times are equivalent.

So, I decided to install Digikam on Samsung notebook. Left it on Wifi and left my MBP on cable.

Configured Digikan on it to access my remote files on NAS.

Started both on my MBP and Samsung.

On my MBP, took 1h45min just to the interface comes up. The message on splash screen was Checking ICC repository.

After that, Digikam started to find new items. 

After 20min: 

    MBP: 0% , Samsung 2%

I could see, on Samsung's digikam interface, it finding the itens. Since I have more than 100.000 items on my library, I know it would take a long time. At least it was working.

After 1h:

   MBP: 0%, Samsung: 8%

I then decided to plug the cable back to Samsung. The speed increased drastically, of course, since it was Gb speed, and on about 10 minutes it passed to 12%.

And after 3 hours, I quit digikam on MBP. Still on 0%.

I don't know what else I can do. Already thinking to changing my computer, but I don't want and I will not, my MBP is quite old (2011), but everything works perfectly on it. 

---- Ativado Qua, 08 abr 2020 15:25:46 -0300 woenx <[hidden email]> escreveu ----

Alex, what is the typical network latency (the milliseconds on each ping) to
the server where the photos are stored?

I spend some time abroad last year and the latency was quite high (~125ms)
despite having a decent network speed (realistically, ~40Mbps). My library
(around 100000 pictures, around 300GB), and digikam took around 9 minutes
just to show the main interface (and many many more to complete the initial
scan). However, the same library, from home (40ms to the server where they
are stored), starts almost immediately and completes the initial scan within
7 minutes, considering there are not new pictures to be found. So,
apparently, network latency matters even more than network speed. I also use
a newer version, so it might have been caused by some bug that is fixed now.

In the case there are new pictures to be found, digikam tried to transfer
them in order to look at the metadata, so the process is slower, but that is
a background process and you can use the program normally meanwhile.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[woenx]

Hi again Alex,

the ping values for your macbook seem to include the decimal point, so
2.055ms in your macbook would be equivalent to 2ms in your samsung. In
English they use the point as a decimal separator, although it is confusing
because other languages like Portuguese or Spanish use a comma, and in
computers sometimes they mix the two. In any case, I think the ping latency
in both computers are normal. The problem must be somewhere else.

The times for scanning your library in your Samsung computer are normal,
it's more or less what it took me to scan the library for the first time.
The computer basically needs to transfer all files one by one and read their
contents. When I have to reinstall digikam in a new computer, I just leave
it scanning for a whole day. Thankfully, subsequent starts will be much
faster since the scan only searches new pictures or pictures that have
changed. If you have the opportunity, I'd do the first scan using Ethernet.

So, maybe the problem is specific to the MacOS version of digikam? In linux
and windows there are ways to launch digikam and see the output in a
console, so problems are easier to detect. I don't have an Apple computer at
hand, so I can't try for myself.

Does anyone else have this problem? Is this a bug?



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Gilles Caulier-4]

Le mar. 21 avr. 2020 à 17:36, woenx <[hidden email]> a écrit :

>
> Hi again Alex,
>
> the ping values for your macbook seem to include the decimal point, so
> 2.055ms in your macbook would be equivalent to 2ms in your samsung. In
> English they use the point as a decimal separator, although it is confusing
> because other languages like Portuguese or Spanish use a comma, and in
> computers sometimes they mix the two. In any case, I think the ping latency
> in both computers are normal. The problem must be somewhere else.
>
> The times for scanning your library in your Samsung computer are normal,
> it's more or less what it took me to scan the library for the first time.
> The computer basically needs to transfer all files one by one and read their
> contents. When I have to reinstall digikam in a new computer, I just leave
> it scanning for a whole day. Thankfully, subsequent starts will be much
> faster since the scan only searches new pictureshttps://www.digikam.org/download/ or pictures that have
> changed. If you have the opportunity, I'd do the first scan using Ethernet.
>
> So, maybe the problem is specific to the MacOS version of digikam? In linux
> and windows there are ways to launch digikam and see the output in a
> console, so problems are easier to detect. I don't have an Apple computer at
> hand, so I can't try for myself.

under mac, it possible to lauch DK from a console as under Linux to
see the debug trace. Details are available here :

https://www.digikam.org/contribute/

Gilles Caulier

[Maik Qualmann]

I suspect that you activated album monitoring in the digiKam Setup->
Collections. Be sure to disable it under MacOS, so your not have a slow start.

Maik

Am Dienstag, 7. April 2020, 00:14:46 CEST schrieb Alex Antão:

> Hi all,
>
>
>
>   I have a NAS which stores all my photos. Configured digikam to it in the
> Network Drive category.
>
>
>
>   My connection is not Slow, My network is all 1 Gigabit and my current wifi
> connection is about 450Mbps
>
>
>
>   Digikam takes about half an hour to load. When it loads, it stays on
> searching for new items for a long, long time. Running on macOS Catalina.
>
>  
>
>   I think it should be a lot faster than that.
>
>
>
>   Also, if the network drive is disconnect at some point, or I start Digikam
> with network drive not mounted, Digikam starts really fast, only showing
> the items of the library but not making any changes to the real files. If I
> reconnect the drive, Digikam does not recognise it and continue working
> "off-line".
>
> Whay do I have an option to catalog a Library as a network drive if it does
> not have any changes as a normal and local library ????
>
>
>
>    Is it a bug ? Is there a way to workaround ?
>
>
>
> Thanks..
>  

[Alex Antão]

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.

I’ll start it from console today and see if there’s some message

Thanks

Enviado do meu iPhone

> Em 21 de abr de 2020, à(s) 12:41, Gilles Caulier <[hidden email]> escreveu:
>
> Le mar. 21 avr. 2020 à 17:36, woenx <[hidden email]> a écrit :
>>
>> Hi again Alex,
>>
>> the ping values for your macbook seem to include the decimal point, so
>> 2.055ms in your macbook would be equivalent to 2ms in your samsung. In
>> English they use the point as a decimal separator, although it is confusing
>> because other languages like Portuguese or Spanish use a comma, and in
>> computers sometimes they mix the two. In any case, I think the ping latency
>> in both computers are normal. The problem must be somewhere else.
>>
>> The times for scanning your library in your Samsung computer are normal,
>> it's more or less what it took me to scan the library for the first time.
>> The computer basically needs to transfer all files one by one and read their
>> contents. When I have to reinstall digikam in a new computer, I just leave
>> it scanning for a whole day. Thankfully, subsequent starts will be much
>> faster since the scan only searches new pictureshttps://www.digikam.org/download/ or pictures that have
>> changed. If you have the opportunity, I'd do the first scan using Ethernet.
>>
>> So, maybe the problem is specific to the MacOS version of digikam? In linux
>> and windows there are ways to launch digikam and see the output in a
>> console, so problems are easier to detect. I don't have an Apple computer at
>> hand, so I can't try for myself.
>
> under mac, it possible to lauch DK from a console as under Linux to
> see the debug trace. Details are available here :
>
> https://www.digikam.org/contribute/
>
> Gilles Caulier

[Alex Antão]

Hummm yes. It’s activated. Will try that too!!!

Enviado do meu iPhone

> Em 21 de abr de 2020, à(s) 14:30, Maik Qualmann <[hidden email]> escreveu:
>
> I suspect that you activated album monitoring in the digiKam Setup->
> Collections. Be sure to disable it under MacOS, so your not have a slow start.
>
> Maik
>
> Am Dienstag, 7. April 2020, 00:14:46 CEST schrieb Alex Antão:
>> Hi all,
>>
>>
>>
>>  I have a NAS which stores all my photos. Configured digikam to it in the
>> Network Drive category.
>>
>>
>>
>>  My connection is not Slow, My network is all 1 Gigabit and my current wifi
>> connection is about 450Mbps
>>
>>
>>
>>  Digikam takes about half an hour to load. When it loads, it stays on
>> searching for new items for a long, long time. Running on macOS Catalina.
>>
>>
>>
>>  I think it should be a lot faster than that.
>>
>>
>>
>>  Also, if the network drive is disconnect at some point, or I start Digikam
>> with network drive not mounted, Digikam starts really fast, only showing
>> the items of the library but not making any changes to the real files. If I
>> reconnect the drive, Digikam does not recognise it and continue working
>> "off-line".
>>
>> Whay do I have an option to catalog a Library as a network drive if it does
>> not have any changes as a normal and local library ????
>>
>>
>>
>>   Is it a bug ? Is there a way to workaround ?
>>
>>
>>
>> Thanks..
>>
>
>
>
>

[Martin Althoff]

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.
>
>

[Alex Antão]

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.

Shanghai, China Copyright (C) 2012-2019 Wang Bin (aka. Lucas Wang) [hidden email]

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 <[hidden email]> 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.
>
>

[Alex Antão]

Seems that the problem really is related to the option to auto check for new files. 

Since yesterday I left my DK scanning my files, it's running fast, on my access point I can see traffic of 30-40Mbps for my computer .

The main interface apears really fast now, the scanning takes a little to start (maybe it's verifying the photos already transferred), but after some time it continues scanning the library. At least I can use the interface normally. 

Thanks for all help ! Let's see when it finishes scanning.

---- Ativado Qui, 23 abr 2020 17:42:55 -0300 Alex Antão <[hidden email]> escreveu ----

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.

Shanghai, China Copyright (C) 2012-2019 Wang Bin (aka. Lucas Wang) [hidden email]

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 <[hidden email]> 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.
>
>

[woenx]

Yep, now it seems that it is behaving normally :)



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html