Bug 130866 - 'gthumb --import-photos' fails with mounted usb-storage device
'gthumb --import-photos' fails with mounted usb-storage device
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gnome-volume-manager (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: John (J5) Palmieri
:
Depends On: 131347
Blocks: FC3Target
  Show dependency treegraph
 
Reported: 2004-08-25 09:39 EDT by Tim Waugh
Modified: 2013-03-13 00:46 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-01 05:50:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Waugh 2004-08-25 09:39:46 EDT
Description of problem:
gnome-volume-manager will invoke 'gthumb --import-photos' when you
plug in a camera and agree to import photos into your photo album. 
However, this fails altogether for cameras that implement USB mass
storage, since they have already been mounted (the check for 'dcim/'
is what triggers the import).

What is the right solution here?  Should gthumb handle this (how can
it know where to copy files from)?  Or gphoto2 (same question)?  Or
should gnome-volume-manager be smarter?

Version-Release number of selected component (if applicable):
gphoto2-2.1.4-2.1
gthumb-2.4.1-1
gnome-volume-manager-0.9.9-2

How reproducible:
100%

Steps to Reproduce:
1. Plug in a USB mass storage camera
Comment 1 John (J5) Palmieri 2004-08-25 15:09:48 EDT
CCing dave on this.  I'm guessing that it is best to for g-v-m not to
mount the drive if import is selected.  Dsrt on #gnome-devel is
working on a dbus gphoto2 daemon which would allow multipule
applications to access a device at once but I am not sure if we can
get this in fc3 or not.  It would also involve porting gthumb.

Another option is to turn off auto importing alltogether for this
release.  
Comment 2 John (J5) Palmieri 2004-08-25 15:10:52 EDT
forgot to cc david
Comment 3 David Zeuthen 2004-08-25 15:48:57 EDT
Uhm, maybe I'm missing something here. 

1. If your camera is USB Mass Storage based g-v-m will think it's a
disk and mount it. The presence of a DCIM tree will trigger the "You
have new pictures" dialog that eventually takes you to 'gthumb
--import-photos'. This will also be true for card readers with media
that has a DCIM tree. I take this is what this bug is about.

2. If your camera is not based on USB Mass Storage and it got the hal
capability 'camera' g-v-m also launch 'gthumb --import-photos' (Btw,
I've written a hal callout that looks at /etc/hotplug/usb.usermap to
use this)

The bug is really upstream in g-v-m; it only gives *one* program for
two *different* uses. 

Suggestion to write patch to g-v-m that enables the program to contain
the HAL UDI (I need to write a few other small patches so I can do
this and I'm confident it will be merged upstream) and write a wrapper
for gthumb that does either 'gthumb /media/usbdisk1' or 'gthumb
--import-photos' depending. Then the g-v-m capplet would contain
'launch-gthumb %h' and all would be well.

Long term solution is more complicated, but this will at least make it
work well for all digital cameras and card readers that are USB
Storage + all digital cameras supported by gphoto2.

Thoughts?
Comment 4 David Zeuthen 2004-08-25 15:54:33 EDT
Ok, I see. What I was missing was the discussion about unmounting and
using gphoto2; I see now. This is not really feasible; we want to
support card readers as well and only very few cameras support both
USB Mass Storage and e.g. PTP as used by gphoto2.
Comment 5 David Zeuthen 2004-08-31 11:26:22 EDT
I got my patch merged upstream in g-v-m after nagging the maintainer;
he even released 0.9.10. I've also built the callouts into hal so we
properly detect gphoto2-based cameras. 

So as I see it only the following things need to be done

1. Add X-Red-Hat-Base to Categories in .desktop file (magicdev was in
base)

2. Install the gvm-gthumb wrapper (there is one at
http://lists.gnome.org/archives/utopia-list/2004-August/msg00100.html)

3. Tweak defaults to point to gvm-gthumb wrapper

(might come up with a better name than gvm-gthumb)
Comment 6 Jef Spaleta 2004-08-31 22:23:23 EDT
Re: Comment #3

Can you explain scenario 1 a little more.

I get the dialog with cancel/import as the options. I select import
and gthumb is just completely confused because it seems to be
expecting a camera and not a mounted filesystem.

Gthumb's import Photos dialog shows up... with a no camera detected
icon.. a destination as /home/username  and blank film and categorie
fields. I try to hit import and I get a 'could not import photos: no
camera detected' dialog. So it appears to me like hal and g-v-m are
doing the clever thing and starting gthumb. but gthumb seems to be
completely confused by the idea of mounted media with a dcim directory
and looks to be expecting a camnera it can probe with libgphoto.
/media/usbdrive/dcim exists and there are photos on the disk.

Do i need to open up a bug against gphoto about this?  What is the
exaxct command that gets run to call gthumb in this case?
does --import-photos take a location argument? How does gthumb know to
look at /media/usbdrive/dcim ?  

-jef

Comment 7 David Zeuthen 2004-09-01 05:50:57 EDT
Hi, this is fixed in Rawhide; you'll need gnome-volume-manager
0.9.10-2 and hal-0.2.97.cvs20040901-1. 

If you have changed the defatuls in the "Removable Storage"
preferences capplet, you need to set 'gthumb-import %h' as the command
to invoke when importing digital photo albums.
Comment 8 Jef Spaleta 2004-09-02 20:28:58 EDT
confirm
fixed gthumb-import %h  opens in the directory.

One thing.. do you want it to open into the dcim subdirectory by
default? instead of the top directory of the media?

-jef
Comment 9 John (J5) Palmieri 2004-09-03 11:33:29 EDT
David, does all photo media have the dcim subdirectory?  If so then
yes.  Actually I can just put a test in the script to see if it exists
and use that directory if it does.  Any objections?
Comment 10 David Zeuthen 2004-09-03 11:49:35 EDT
Yeah, although dcim may be in uppercase as well IIRC. Putting it in
the script will help but the user will still have to select the subdir
with the pictures and this is camera specific. My camera uses canon122
and so forth. 

All detailed in DCF, see http://www.exif.org/dcf.PDF (btw this doc
raises some interestering requirements for the Perfect(tm) photo mgmt
app; e.g. Reader 2 playback; ask to print tagged pictures etc.)
Comment 11 Tim Waugh 2004-09-03 11:55:08 EDT
Also note that there may be several subdirectories below DCIM if the
media has been used with different devices.
Comment 12 Jef Spaleta 2004-09-03 18:49:52 EDT
my point is... if the request for importing the pictures from media
is done just by checking for a dcim or DCIM directory to even get the
dialog, it makes some sense to open up to the dcim directory becuase
im not all that sure that Al "the average user" Consumer is going to
know that DCIM is the directory to browse down into. If the existance
of the dcim directory is indeed what triggers the prompt open up to
that directory.

My camera, and i would imagine other cameras. let me name the
subdirectories under DCIM to some extent and I can even choose which
directory to use from the camera menu... the menu item right above "do
my taxes" and just below "save the whales."  Regardless though, seeing
a set of subdirectories named NikonXXX or CanonXXX is going to be much
more intutitively understood as photo directories than DCIM.

-jef"my 3 cents, you own me 1 penny in change"spaleta

Comment 13 John (J5) Palmieri 2004-09-04 17:16:09 EDT
Hehe, I guess I should have posted earlier but this is fixed and
holding for after FC3 test2 is out.  The bug is not critical enough to
hold up test2 in QA.  The wrapper script just checks to see if the
dcim or DCIM directory exists and uses that as the base directory.

Just as refrence this should have been opened up as a new bug, not
appended to an already closed bug.

Closed for real this time ;-)

Note You need to log in before you can comment on or make changes to this bug.