Bug 453503 - digikam cannot detect Samsung Android phone
Summary: digikam cannot detect Samsung Android phone
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Import-Gphoto2 (show other bugs)
Version: 7.6.0
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-05-07 13:14 UTC by tnemeth
Modified: 2023-10-11 19:05 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 8.2.0
Sentry Crash Report:


Attachments
Failure to connect to phone. (160.17 KB, image/png)
2022-05-07 13:14 UTC, tnemeth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tnemeth 2022-05-07 13:14:40 UTC
Created attachment 148634 [details]
Failure to connect to phone.

SUMMARY
When trying to download photos from my phone (a process that I used a lot of time before, with previous versions of digikam), my phone cannot be detected / accessed by digikam even though permissions to access have been granted from the phone (and, in fact, accessing them through dolphin works).


STEPS TO REPRODUCE
1. plug in the phone
2. start digikam either from the menu or from the "download photos with digikam" in the removable devices notification one
3. try to download photos from autodetected (or manually configured) phone.

OBSERVED RESULT
An error saying "Failed to connect to the camera. Please make sure it is connected properly and turned on."

EXPECTED RESULT
All photos of the phone be displayed in the selection window.

SOFTWARE/OS VERSIONS
Operating System: Debian GNU/Linux
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.17.0-1-amd64 (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i7-7567U CPU @ 3.50GHz
Memory: 31.3 Gio of RAM
Graphics Processor: Mesa Intel® Iris® Plus Graphics 650


ADDITIONAL INFORMATION
A workaround is to copy images through dolphin into a local directory then import them... Then remove manually those which have been incorporated in digikam.
Comment 1 Maik Qualmann 2022-05-07 13:32:44 UTC
Please create a debug log from the terminal as described here:

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

However, the cause is the start via the notification applet, which means that the GPhoto2 USB port is already in use by the system applet. digiKam needs direct access to the USB port. We do not support camera KIO* services or the corresponding Gnome services.

Maik
Comment 2 caulier.gilles 2023-05-02 06:24:02 UTC
@tnemeth@free.fr

Do you seen the comment #1 from Maik ?

Gilles Caulier
Comment 3 tnemeth 2023-05-02 07:14:09 UTC
(In reply to caulier.gilles from comment #2)
> @tnemeth@free.fr
> 
> Do you seen the comment #1 from Maik ?

    No, sorry, I haven't seen it until now :(
Comment 4 caulier.gilles 2023-10-11 05:48:42 UTC
@tnemeth@free.fr,

What's about this file using current 8.2.0 AppImage Linux bundle ? It's
reproducible ?

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

Thanks in advance

Gilles Caulier
Comment 5 tnemeth 2023-10-11 16:20:30 UTC
(In reply to caulier.gilles from comment #4)
> @tnemeth@free.fr,
> 
> What's about this file using current 8.2.0 AppImage Linux bundle ? It's
> reproducible ?
> 
> https://files.kde.org/digikam/
> 
> Thanks in advance
> 
> Gilles Caulier

Hi Gilles.

Just reading your message remembered me that I still had to give you an output of the application -_-;

Starting digikam from the command line with the --detect-camera option made digikam... detect and access my phone.
I'm using digikam 8.1.0.
It also seems to be fixed when using the device notification associated action "Download photos with digikam".

Note that android has been updated several times since my last try as well as digikam itself. I'm sorry I couldn't test it better before.

Well now digikam can download photos (and much more that are not even photos unfortunately)... but can't display anything while still locked at 30% of "Looking up for new elements" in the progress bar at the bottom of the window (progression is VERY slow). This should be described another BR, I suppose.

Anyway, I think this BR can be closed as "fixed".

Thanks.