[digiKam-users] How to interpret DigiKam error message when connecting to camera
Locked
[digiKam-users] How to interpret DigiKam error message when connecting to camera
 
|
I'm new to Digikam. I'm trying to ingest images into DK under linux Mint
19.3 from my USB connected Fujifilm X-T20. The camera is correctly identified by DK, but an error message says DK cannot connect to the camera and asks me to make sure the camera is connected properly and switched on. I believe that both of these requirements are met because other apps. (XnView, Rapid Photo Downloader, Mint file explorer) can read the camera SD card. The error message is misleading, possibly wrong. How do I make DigiKam present the real problem it is having, so that I can ingest images from the camera? Under windows, on another computer, DK is unable to detect the camera and I don't understand the settings to be entered to manually identify the camera to DK. How to I set these parameters? |
Re: How to interpret DigiKam error message when connecting to camera
|
|
You do need to dismount the camera. I also run DK in Mint, when I plug
the camera in I get a pop-up box asking what to do, open as folder, open with something else, etc, and there is an 'Unmount' button as well, click this and DK should allow the import. Alternatively if it is already mounted click on the up arrow to the right of the camera name in file explorer. Hope that helps. Having to dismount to import did seem a bit odd to me as well:) Mick On 27/06/2020 00:06, tony Hamilton wrote: > I'm new to Digikam. I'm trying to ingest images into DK under linux > Mint 19.3 from my USB connected Fujifilm X-T20. The camera is > correctly identified by DK, but an error message says DK cannot > connect to the camera and asks me to make sure the camera is connected > properly and switched on. I believe that both of these requirements > are met because other apps. (XnView, Rapid Photo Downloader, Mint file > explorer) can read the camera SD card. The error message is > misleading, possibly wrong. How do I make DigiKam present the real > problem it is having, so that I can ingest images from the camera? > > Under windows, on another computer, DK is unable to detect the camera > and I don't understand the settings to be entered to manually identify > the camera to DK. How to I set these parameters? > |
|
|
I quite agree: "DK should allow the import". Sadly, DK doesn't agree with us. After almost 2 days of continuous playing around with this - focussing on the automount factor - I have made zero progress. I note also that there is very little available via Google search in the way of solutions, although plenty of people have a similar problem. I can't understand this: I am able to browse the content of the SD card in my USB connected camera from Nemo. DK even autodetects the camera - and then tells me it is not connected, when it clearly and effectively is. I have to ask: was this function fully tested? 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 and the card is not really meant to be repeatedly removed from and re-inserted into the camera. The function to read from the card while still in the camera is, apparently, a function of 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)? On Sat, 27 Jun 2020 at 12:39, Mick Sulley <[hidden email]> wrote: You do need to dismount the camera. I also run DK in Mint, when I plug |
|
|
On Sat, 27 Jun 2020 17:20:55 +0100
a squared <[hidden email]> 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?... |
Re: How to interpret DigiKam error message when connecting to camera
|
|
In reply to this post by a squared
On Sat, Jun 27, 2020 at 05:20:55PM +0100, a squared wrote:
> I quite agree: "DK should allow the import". Sadly, DK doesn't agree > with us. > After almost 2 days of continuous playing around with this - focussing > on the automount factor - I have made zero progress. I note also that > there is very little available via Google search in the way of > solutions, although plenty of people have a similar problem. I can't > understand this: I am able to browse the content of the SD card in my > USB connected camera from Nemo. DK even autodetects the camera - and > then tells me it is not connected, when it clearly and effectively is. > I have to ask: was this function fully tested? 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 and the card is not really meant to > be repeatedly removed from and re-inserted into the camera. The > function to read from the card while still in the camera is, > apparently, a function of 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)? > system should take care of file handling. I just connect my camera (by USB) and the OS mounts it automatically. I then copy the files from the camera into my Digikam album directory and the job is done. Why should Digikam duplicate the (extensively tested and debugged) OS file management utilities? -- Chris Green |
|
|
In reply to this post by digikam-2
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, <[hidden email]> wrote: On Sat, 27 Jun 2020 17:20:55 +0100 |
Re: How to interpret DigiKam error message when connecting to camera
|
|
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, <[hidden email] > <mailto:[hidden email]>> wrote: > > On Sat, 27 Jun 2020 17:20:55 +0100 > a squared <[hidden email] <mailto:[hidden email]>> 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 |
Re: How to interpret DigiKam error message when connecting to camera
|
|
The problem is the service that under Ubuntu immediately seizes the camera
device and does not release it again. Something similar would also happen with a KF5 desktop if Dolphin is opened and the camera is opened. However, the camera KIO slaves are removed after a while. DigiKam wants to address the USB device itself directly. Otherwise we would have to support either KIO or the Ubunto service depending on the desktop. Both are not realistic for an AppImage due to the large dependencies. I see it as an error that the service permanently blocks the gPhoto2 driver under Ubuntu. It is clear that GTK programs that access the service work. Maik Am Sonntag, 28. Juni 2020, 16:34:13 CEST schrieb Stuart T Rogers: > 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, <[hidden email] > > > > <mailto:[hidden email]>> wrote: > > On Sat, 27 Jun 2020 17:20:55 +0100 > > > > a squared <[hidden email] <mailto:[hidden email]>> 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?... |
|
|
In reply to this post by Stuart T Rogers
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 <[hidden email]> wrote: I do not want to enter into the discussion here about the rights and |
Re: How to interpret DigiKam error message when connecting to camera
|
|
Well I have been able to recreate the message from Digikam but only by
having the camera open in Dolphin file manager and accessing the files, then Digikam fails to connect. One interesting point I have found is that if I have the camera open in Dolphin accessing the files then I can also open the camera in Gwenview at the same time but still not in Digikam. This does mean to me that Digikam is accessing the camera using a different method to that of some other applications. I have also tested Darktable and it also is unable to access the camera if it is open in another app like Dolphin or Gwenview, so it looks like Darktable uses the same method as Digikam and would likely exhibit the same issue on your system (it shows no supported devices when I try to scan for devices on import). Also on checking how my distro manages removable devices I have it set to NOT auto mount anything at all! I think the only resolution for you would be to raise this as an issue with your distro as it looks like Digikam is working as designed. Stuart On 29/06/2020 14:50, a squared wrote: > 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 > <[hidden email] <mailto:[hidden email]>> 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, <[hidden email] > <mailto:[hidden email]> > > <mailto:[hidden email] > <mailto:[hidden email]>>> wrote: > > > > On Sat, 27 Jun 2020 17:20:55 +0100 > > a squared <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> 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 <http://www.broadstairs.org> > -- Website: https://www.stella-maris.org.uk or: https//www.broadstairs.org |
Re: How to interpret DigiKam error message when connecting to camera
|
|
On lundi 29 juin 2020 18:01:27 CEST Stuart T Rogers wrote:
> Well I have been able to recreate the message from Digikam but only by > having the camera open in Dolphin file manager and accessing the files, > then Digikam fails to connect. > > One interesting point I have found is that if I have the camera open in > Dolphin accessing the files then I can also open the camera in Gwenview > at the same time but still not in Digikam. This does mean to me that > Digikam is accessing the camera using a different method to that of some > other applications. I have also tested Darktable and it also is unable > to access the camera if it is open in another app like Dolphin or > Gwenview, so it looks like Darktable uses the same method as Digikam and > would likely exhibit the same issue on your system (it shows no > supported devices when I try to scan for devices on import). > > Also on checking how my distro manages removable devices I have it set > to NOT auto mount anything at all! > > I think the only resolution for you would be to raise this as an issue > with your distro as it looks like Digikam is working as designed. That would be consistent with the computer using the MTP protocol to access the camera. Iirc, that protocol allows only one access at the time to the file system on the camera, so once KDE/Plasma grabs the device, Digikam won't have access anymore. Same for Darktable, as neither is using the KDE libraries (gPhoto2 is used to access the camera). That also means that the distro works as designed, as the failure is inherent to the protocol used. So there are two options: - tell the camera to behave as a mass storage device (if that's possible), then it can be mounted as an external drive - use a card reader Remco (P.S. I told OP the same thing in his parallel thread, he chose to skip over the MTP bit, and just started ranting about how using a card reader was more complicated and bad for the SD card, he is now ignored both here and in the dt list) |
Re: How to interpret DigiKam error message when connecting to camera
|
|
I understand, however surely the distro should allow the user set the option to not allow automounting just as openSUSE does. Is that not a bug in the distro?
Stuart On 29 June 2020 17:28:53 BST, "Remco Viëtor" <[hidden email]> wrote: >On lundi 29 juin 2020 18:01:27 CEST Stuart T Rogers wrote: >> Well I have been able to recreate the message from Digikam but only >by >> having the camera open in Dolphin file manager and accessing the >files, >> then Digikam fails to connect. >> >> One interesting point I have found is that if I have the camera open >in >> Dolphin accessing the files then I can also open the camera in >Gwenview >> at the same time but still not in Digikam. This does mean to me that >> Digikam is accessing the camera using a different method to that of >some >> other applications. I have also tested Darktable and it also is >unable >> to access the camera if it is open in another app like Dolphin or >> Gwenview, so it looks like Darktable uses the same method as Digikam >and >> would likely exhibit the same issue on your system (it shows no >> supported devices when I try to scan for devices on import). >> >> Also on checking how my distro manages removable devices I have it >set >> to NOT auto mount anything at all! >> >> I think the only resolution for you would be to raise this as an >issue >> with your distro as it looks like Digikam is working as designed. > >That would be consistent with the computer using the MTP protocol to >access >the camera. Iirc, that protocol allows only one access at the time to >the file >system on the camera, so once KDE/Plasma grabs the device, Digikam >won't have >access anymore. Same for Darktable, as neither is using the KDE >libraries >(gPhoto2 is used to access the camera). > >That also means that the distro works as designed, as the failure is >inherent >to the protocol used. > >So there are two options: >- tell the camera to behave as a mass storage device (if that's >possible), >then it can be mounted as an external drive >- use a card reader > >Remco > >(P.S. I told OP the same thing in his parallel thread, he chose to skip >over >the MTP bit, and just started ranting about how using a card reader was >more >complicated and bad for the SD card, he is now ignored both here and in >the dt >list) -- Sent from my Samsung Galaxy J5 with K-9 Mail. Please excuse my brevity. |
|
|
Ah, life in cyberspace: never a dull moment or unexpected (over) reaction. I am not sure how responder Remco, who is clearly knowledgeable, was able to see inside my brain to discover that I 'chose to skip over the MTP bit...'. Could there be another explanation - that I didn't understand it, not being so knowledgeable and slightly 'doddery' given my age, hmmm? Perhaps that is also why I am unable to understand how my statements on the 'hassle' of using a card reader can be characterised as a 'rant'. My dictionary defines 'rant' as 'to utter in loud, violent or bombastic tones'. Could I have an analysis of which parts of my statement match which parts of the definition? Aside from all that it is most useful to know that I am ignored 'here' (where ever 'here' is) and in the 'dt list', whatever that is. But how does Mr. Remco know that I am ignored in these two places? Has there been a comprehensive survey of the two audiences ? I would be surprised - disappointed even - that people would choose to ignore me without doing me the courtesy of saying why. That's hardly a civilised way to behave. On a more optimistic note, I have now found a procedure that will allow me to repeatedly and reliably read and transfer images directly from either of my two cameras, using DK 6.4.0 Appimage, under Mint 19.3. The procedure strongly suggests that my previous failures were not user error and the details of which could possibly, in the hands of technically qualified people, clarify whether there is a problem in the build of the 6.4.0 DK appimage, or a defect in the 19.3 version of Mint Cinnamon. However, as I am assured that I am being ignored, and the issue I was facing having gone away, I'll close the discussion here. On Mon, 29 Jun 2020 at 18:17, Stuart Rogers <[hidden email]> wrote: I understand, however surely the distro should allow the user set the option to not allow automounting just as openSUSE does. Is that not a bug in the distro? |
Re: How to interpret DigiKam error message when connecting to camera
|
|
In reply to this post by Stuart T Rogers
On lundi 29 juin 2020 19:17:41 CEST Stuart Rogers wrote:
> I understand, however surely the distro should allow the user set the option > to not allow automounting just as openSUSE does. Is that not a bug in the > distro? But if the camera is accessed through the MTP protocol, *nothing is auto- mounted* in the sense of becoming part of the file system. That part of the system doesn't even come in play, as it is used for "mass storage devices". But you say you can't get dk or dt to download files *when dolphin or gwenview are looking at the data*. Those programs use a KDE interface to access the device, and thus block it (you'll probably have a line starting with "mtp: " above the file list in Dolphin). So gPhoto2 can't access the camera... And when I had a look at the camera manual, there wasn't much information about the protocols used. (e.g. apparently no "mass storage" option...). Remco |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |