[digiKam-users] How to interpret DigiKam error message when connecting to camera

[a squared]

Thank for the observations. My procedure is just about identical until I
get to step 4. There is no pop-up identification  and I do know what you
mean because I have seen this in the past, but this no longer happens, even
if I insert a simple USB memory stick.

Starting DigiKam at this point  leads me back to the inevitable message
that DK cannot connect to the camera - even though it can auto-detect it.
In addition, other apps. like Rapid Photo Downloader and XnView are able
to 'see' and open the SD card in the camera.

There are no other messages from DK.

The system log is of course huge and mostly beyond my understanding. I can
see in it the detection of my USB memory sticks and also a "USB PTP Camera"
but the messages do not imply any error, to me. The final entry in the log
might be significant; is says "gvfsd-metadata(2179) : g-udev_device
_has_property: assertion 'G_UDEV_IS_DEVICE (device)' failed" - that is the
only obvious error message I can see, but it has no meaning to me.

The camera, is as previously stated, a Fujifilm X-T20, with body firmware
at the latest level announced by Fuji; I know of no way of further
specifying the term 'exact model'

The USB connection type is, of course, USB 2.0, as fixed by the camera.

The type of cable is, as specified by  Fuji:, a Micro-USB 2.0 Type B. Fuji
give a very clear close-up  photo illustration of both ends of the
necessary cable in an FAQ, dated 16 March 2020, on their camera support
web-site. In fact I have 3 such cables, of 30, 75 and 120 cm length, all
within the cable length limit of 1.5m. The failure of DK to connect to the
camera happens with all of these cables. I am able to use Lightroom, rapid
Photo Downloader and XnView (at least) successfully with all 3 of these
cables, on 4 different computers.

I'm using DK version 6.4.0 in Appimage form.

Actually I have the belief that a key to the issue as hinted at in the post
by Maik Qualmann: Ubuntu (or Mint) immediately seizes the camera device
upon connection and does not release it again. I had tried altering the
preferences found in the Nemo File Explorer in Mint. Under the 'Behaviour'
tab in <Edit><Preferences> there is a section for 'Media Handling'
containing 4 on/off options. Specifically I have tried setting the
'Automatically mount removable media when inserted and on startup' option
on and off. I was advised in another forum, dealing with the same issue in
DarkTable, that this option prevents the device being seized by the Kernel
in this way, but I don't believe it: setting this option makes no
difference to DK's ability to connect to the camera. Setting the option on
has the only one effect I can observe of placing a 'USB PTP CAMERA' folder
on my desktop. Attempts to open this folder in DK fail; attempts to open in
RPD succeed, but the folder is immediately deleted from the desktop.

I have tried all possible combination of the settings of these 4 media
handling options, with a system restart between each change. DK is unable
to connect to the camera in all circumstances.

I know of no further steps to do definitive Problem Source Identification;
the DK developers have published no relevant MAPS for this purpose.


On Sun, 28 Jun 2020 at 15:34, Stuart T Rogers <stuart at stella-maris.org.uk>
wrote:

> I do not want to enter into the discussion here about the rights and
> wrongs of the thread.
>
> I just wanted to say that as a test I decided to download my latest
> photos from my camera using a USB cable to see what happened as I
> normally use a card reader. I am using openSUSE Tumbelweed and Digikam
> 6.4 and my Pentax K-70 camera on a USB 2 connection using a standard USB
> cable.
>
> So here is what I did
>
> 1. plug in USB cable into camera
> 2. plug USB cable into computer
> 3. turn on camera
> 4. PC pops up the notification about the camera being connected with the
> usual options about viewing or downloading photos with a file manager,
> Gwenview or Digikam, all of which I ignored.
> 5. started Digikam and when up selected target album to import into.
> 6. selected Import/Cameras and then my camera which was marked as
> auto-detected.
> 7. Digikam opened the window and loaded a preview of all the images on
> the camera.
> 8. selected the newest images and then Download Selected and images
> appeared in the album just fine.
>
> So I can say without doubt that Digikam does indeed support import from
> a camera.
>
> So if it does not work on your setup all I can say is that it needs more
> information, you need to explain exactly what of the above process fails
> and whether or not there are any error messages from digikam and your
> system log which might indicate where an error might exist, knowing what
> the exact model of camera, type of USB connection (USB 1 2 or 3), what
> type of cable and which version of Digikam might help to resolve you issue.
>
> Stuart
>
> On 28/06/2020 13:33, a squared wrote:
> > I do not know who Dilbert, or his boss, are and knowing now that I sound
> > like them hasn't informed me more about the cause of the problem I am
> > having. Please explain the significance of your assessment.
> >
> > I have now examined the SD Card Association's Simplified Specification
> > for these cards. The insertion/ejection life cycle data has been removed
> > from the specification. Other analyst's assessments, discoverable by a
> > Google search, suggest a life-time of thousands of cycles. This implies
> > that these devices are physically robust beyond average consumer
> > requirements. Electrical read/write cycle life time appears, from
> > similar sources, to be in the many 10's of thousands of cycles. My
> > comment about SD cards not being meant to be repeatedly inserted/removed
> > was an opinion that is/was wrong. Mea culpa.
> >
> > However, I believe there is more work involved in using a card reader
> > than in directly connecting a camera. I think it is not necessary to
> > detail the individual steps of the two techniques in order to support my
> > view. On my Fuji camera, if I don't exploit the technique of allowing
> > the spring to forcibly eject the card, then it takes quite a bit of
> > messing about,  in a very confined space, to get one's fingers around
> > the card to pull it out.  If I use the spring, the card is fired more
> > than a meter or two away from the camera and has been known to land in
> > my cup of tea. Directly connecting the camera is easier.
> >
> > My point about the function of reading the card while it is in the
> > camera being implemented within DK is that DK should therefore provide a
> > more meaningful error message than that which I receive. You have
> > elaborated  and provided a more complete analysis, confirming that DK is
> > involved in this process. My point stands, does it not ?
> >
> > About your numbered comments:
> > 1. The number of people successfully using DK, or the size of their data
> > transfers, has no bearing on the fact that it doesn't work in my
> > environment. I have few skills, but I do clearly remember, almost 40
> > years ago when I had global responsibility for technical support  -
> > hardware and software  - for a range of computer systems , that one of
> > my biggest challenges was to teach my staff that because we didn't have
> > a problem didn't mean that our customers didn't have problems. The
> > operating environments are different. the factors that can invoke an
> > error situation are different. Don't castigate the victim.
> >
> > 2. If you have a mind set that looks for insulting assertions, you are
> > possibly bound to find them. That is no proof that they exist or were
> > intended.
> >
> > 3. I thought that my original post was a request for help.
> >
> > 4. I'm not sure what level of detail you are suggesting should have been
> > included in my original post; cables, for instance: what are  the
> > salient and relevant properties and how could I assess and enumerate
> > them? How would I know what else is running that is relevant? The list
> > of active processes in Cinnamon is pretty daunting; how do I know
> > which are relevant? In fact this is a back-to-front approach to PSI: a
> > technical support person should be telling me precisely what information
> > is required and how I should acquire it. It is my contention that DK
> > knows precisely why it is unable to communicate with my camera and that
> > this should point me to the necessary solution, instead of providing me
> > with a generic 'computer says no' style of error. That is just lazy
> > programming. if somebody feels insulted by that they need some
> > counselling on self assurance.
> >
> > In conclusion, I have decided that my installation of DK is functionally
> > unable to read from a directly connected camera and I have reverted to
> > using a card reader. Life is too short -for me.
> >
> > On Sat, 27 Jun 2020 at 18:29, <digikam at 911networks.com
> > <mailto:digikam at 911networks.com>> wrote:
> >
> >     On Sat, 27 Jun 2020 17:20:55 +0100
> >     a squared <amfev44 at gmail.com <mailto:amfev44 at gmail.com>> wrote:
> >
> >      > I have to ask: was this function fully tested?
> >
> >     You sound like Dilbert's pointy-hair boss :(
> >
> >      > The scenario suggests there is some difference of opinion between
> >      > Linux and DK.  I'm not capable of figuring this out. Yes, I could
> >      > remove the SD card and use a card reader, but this is a hassle
> >
> >     Yes I understand but to me it's not anymore hassle than plugging and
> >     unplugging the camera into the computer
> >
> >      > and the card is not really meant to be repeatedly removed from and
> >      > re-inserted into the camera.
> >
> >     Uh? Why? What qualification do you have to make such a statement?
> >
> >      > The function to read from the card while still in the camera is,
> >      > apparently, a function of DK.
> >
> >     Actually it's a function of the OS, the camera, the transport
> >     protocol and the software (DK)
> >
> >      >
> >      > When will it be offered in a working form or when will effective
> >      > problem source identification procedures be provided (that's a
> >      > question to the developers)?
> >
> >     1. There are tenS of thousandS of users that are using DK everyday,
> >     including me, getting their images into DK with some very large
> >     libraries.
> >     2. I find your assertions very insulting to the people that have
> >     worked and have contributed very hard to DK.
> >     3. Instead, you could state that you have a problem with... and some
> >     people would try to help.
> >     4. You have not provided any useful information like computer,
> >     camera, cables, what else is running... what are the exact steps?...
> >
>
> --
> Website: https://www.stella-maris.org.uk
> or:      https//www.broadstairs.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20200629/e2f9829f/attachment.htm>