After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 160232 - gthumb doesn't import pictures from ARGUS DC1500 camera
gthumb doesn't import pictures from ARGUS DC1500 camera
Status: RESOLVED FIXED
Product: gthumb
Classification: Other
Component: general
2.4.x
Other other
: Normal normal
: ---
Assigned To: Paolo Bacchilega
Paolo Bacchilega
: 160432 304851 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-12-02 16:49 UTC by bb
Modified: 2006-10-19 13:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description bb 2004-12-02 16:49:37 UTC
Distribution: Fedora Core release 3 (Heidelberg)
Package: gthumb
Severity: major
Version: GNOME2.8.0 2.4.x
Gnome-Distributor: Red Hat, Inc
Synopsis: gthumb doesn't import pictures from ARGUS DC1500 camera
Bugzilla-Product: gthumb
Bugzilla-Component: general
Bugzilla-Version: 2.4.x
Description:
Description of Problem:
gthumb doesn't import pictures from ARGUS DC1500 camera.
But, using the gphoto command line interface, I can import photos.

Steps to reproduce the problem:
1. Connect ARGUS DC1500 camera to USB port
2. (if necessary start gphoto, File->Import photos...)
3. Press the import button to attempt to import photos

Actual Results:
No photos imported

Expected Results:
Successfully imported photos

How often does this happen?
Every time

Additional Information:
The gphoto driver for this camera claims that it can't can't get
thumbnails (or do lots of other functionality).
gtkam works fine, but is no longer supported under fedoracore 3.




------- Bug moved to this database by unknown@bugzilla.gnome.org 2004-12-02 11:49 -------


Unknown platform unknown. Setting to default platform "Other".
Unknown milestone "unknown" in product "gthumb".
   Setting to default milestone for this product, '---'
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here, unknown@bugzilla.gnome.org.
   Previous reporter was bb@NOSPAMmail.net.
Setting to default status "UNCONFIRMED".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.

Comment 1 Justin Barrett 2004-12-29 08:50:12 UTC
This is an issue but not sure if this is a gThumb or RedHat issue so I'm not
going to suggest that this be moved to CONFIRMED as I'm not sure what the
problem is.  I'm currently trying to upgrade RH's gThumb (from source) to see if
that helps.  Using gphoto2 from the command line works a-ok.

The camera in question is an Argus DC-1500 which takes on many forms.  I
currently have three different models of the Argus DC-1500 (iConcepts, DigiMax,
and The DC Blue! camera).  You can find these cameras at Wal-Mart/KMart for
$12.99 ~ $19.99. I can repeat the error you are having to the T every install
(of RedHat Fedora Core 3) and on all three of my machines.

Will report if I get any results from the upgrade.
Comment 2 Colin Murtaugh 2005-01-29 16:01:20 UTC
*** Bug 160432 has been marked as a duplicate of this bug. ***
Comment 3 Alexander Boström 2005-02-05 23:37:20 UTC
I have a theory on what happens here.

In dlg-photo-importer.c, gp_camera_file_get_info() is called. In this case I
think it is the call from get_file_list() that is relevant.

There are situations when gp_camera_file_get_info() will trigger att call to the
error callback in the context structure, even though the return value will be
GP_OK and even though the import really could continue. This happens when the
camera driver doesn't implement the get_info_func. That's an odd API, but I
asked about this on the gphoto-devel list, and the reply was that gthumb really
should ignore the error callback when the return code is GP_OK.

Also, in these cases when get_info_func is not implemented in a gphoto driver,
gphoto will not provide any mime type for files on that device.

So to fix this, gthumb needs to change two things:

 * Reset data->error to FALSE is the return code is GP_OK, or something along
those lines.

 * Instead of ignoring any file that doesn't have a proper mime type, gthumb
must also look for a known file extension.

It could be argued that gphoto should guess the mime type based on the
extension, or that all gphoto drivers should implement the get_info_func. But
you'll have to ask the gphoto developers about that. :-)

I have seen this happen with a camera using the "mars" driver, but I no longer
have that camera so I can't reproduce this problem any more. The problem did go
away when I implemented get_info_func for that driver. (Yes, patch submitted and
accepted in gphoto.)

My mail to gphoto-devel, and the reply:
http://sourceforge.net/mailarchive/forum.php?thread_id=6416430&forum_id=32960
Comment 4 Paolo Bacchilega 2005-02-06 10:43:14 UTC
I just committed a patch that implements what you say, someone who had this
problem should test it now.
Comment 5 Michael Chudobiak 2006-09-27 13:17:55 UTC
*** Bug 304851 has been marked as a duplicate of this bug. ***
Comment 6 Michael Chudobiak 2006-10-19 13:00:43 UTC
This bug and its duplicates haven't seen any activity for a while, so I'm marking it as fixed. Please re-open if you are still experiencing problems.

- Mike