Bug 412894

DigiKam-6.3.0 and also the pre-release digiKam-6.4.0 is ready and compiled for MacOS Catalina.

Read also this:
http://digikam.1695700.n4.nabble.com/digiKam-users-Digikam-will-not-run-on-latest-MacOS-Catalina-td4709449.html

Maik

Thank you for the reminder. I've installed the latest weekly snapshot of digiKam 6.4.0. It generally works well with macOS 10.15 Catalina, but the Import window still locks up digiKam when opened.

I've also had this bug consistently over the last 2 versions of Digikam and MacOS.  I let it try to comp[lete for 2 days, and no progress.  After the 2-day test, my OS was corrupted, Safari and Apple App Store (and possibly other apps) caused system exceptions (attempt to execute invalid instruction). Reinstall of MaxOS fixed Safari and App Store, but Digikam, and Digikam after reinstall failed as before.  This is my first bug report, but I'll try to attach Activity force quit reports.  I have also consistently filed reports with Apple when offered.

Activity Monitor reports create apparently garbage pdf files which are too big to attach.  I'll pursue this one with Apple, hopefully in parallel with Digikam fix process.

Created attachment 124791 [details]
text report from force quit of hung import DigiKam not responding

The Import tool was designed to display images from cameras or memory cards. So for a few thousand images. But not for hard drives with tens of thousands of images. The thumbnail model cannot process this large number of images without a database and is getting slower and slower.

Maik

Created attachment 124816 [details]
attachment-31492-0.html

OK, I can understand that. Could it be a little more defensive?  Maybe:
Check the size of the target and if too big ask for a folder?
Or just come back with a “too big” dialog?

There may actually be a bug there, too. Please consider the following:
1.  When I let it run for 3 days, it apparently corrupted the OS. Safari
and Apple App Store started crashing with “invalid instruction codes.
2.  On my system, it seems to generate multiple identities for mounted
disks remembered from previous instances. Most of the phantom disks show
“fail to connect” dialog. The phantoms don’t seem to agree exactly with
information I see in finder or disk utility. Could there be a file system
interface issue that’s making it worse?


On Tue, Dec 31, 2019 at 3:19 PM Maik Qualmann <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=412894
>
> --- Comment #6 from Maik Qualmann <metzpinguin@gmail.com> ---
> The Import tool was designed to display images from cameras or memory
> cards. So
> for a few thousand images. But not for hard drives with tens of thousands
> of
> images. The thumbnail model cannot process this large number of images
> without
> a database and is getting slower and slower.
>
> Maik
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

Hi,

Can you check if this problem still exist with last weekly bundle build of digiKam 7.0.0 available here:

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

Thanks in advance

Gilles Caulier

digiKam 7.0.0 stable release is now published:

https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/

We need a fresh feedback on this file using this version.

Thanks in advance

Gilles Caulier

Created attachment 130531 [details]
attachment-14005-0.html

It will be several weeks before I can update and test this release, as
requested in todays email from Gilles/bugzilla. I’m in Covid retreat in a
place with very weak internet service until late fall.
Thanks for all the work that you did in the new release.

On Tue, Dec 31, 2019 at 3:19 PM Maik Qualmann <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=412894
>
> --- Comment #6 from Maik Qualmann <metzpinguin@gmail.com> ---
> The Import tool was designed to display images from cameras or memory
> cards. So
> for a few thousand images. But not for hard drives with tens of thousands
> of
> images. The thumbnail model cannot process this large number of images
> without
> a database and is getting slower and slower.
>
> Maik
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

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

--- Comment #4 from caulier.gilles@gmail.com ---
Hi,

digiKam 7.2.0-beta2 pre-release PKG installer now support BigSur and is
compiled with last stable Qt 5.15.2.

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

Problem still reproducible with this version.

Thanks and happy Christmas in advance

Best Regards

Gilles Caulier

digiKam 7.2.0 official release is published with more than 360 files closed from bugzilla:

https://www.digikam.org/news/2021-03-22-7.2.0_release_announcement/

Can you reproduce the dysfunction with this version ?

Thanks in advance for your feedback

Gilles Caulier

*** Bug 461871 has been marked as a duplicate of this bug. ***

*** Bug 407738 has been marked as a duplicate of this bug. ***

@styleling,

digikam 8.2.0 pre-release have been rebuilt using last Qt 5.15.11 + KDE 5.110
frameworks. Installer is available at usual place :

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

Can reproduce the problem with this version?

Thanks in advance

Gilles Caulier

Hi. As an updated.  I tried the latest, 8.2.0 prerelease, Build date: 10/19/23 on MacBook M2 with 13.6 (22G120). 
I tried connecting iPhone via cable and Nikon camera via cable.  
The Import interface just said: Failed to connect to the camera. Please make sure it is connected properly and turned on.
Neither the Nikon or iPhone were listed, but the SSD which is part of the library was listed as a drive.  

It did not crash, scan, hang, or require a force close. It basically did nothing.   Just didn't do anything to find images on iPhone or Nikon.  So that may be an improvement that it doesn't hang.  
I have gotten used to importing images in a different way using Finder directly from the Nikon's SD card, so this bug doesn't really affect me now.

Ok, thanks for the feedback.

I close this file now, as the original problem is solved.

The import camera feature with Gphoto2 is already reported in bugzilla by one other file. It's typically a problem of right to grant to the application to access to the camera through the USB port.

Gilles Caulier