Bug 552890

p.s.

If you don't have time to work on this, and are ok with it I can commit and build this my self for rawhide + F-12, and also create an F-12 update in bodhi.

(In reply to comment #0)
> Created an attachment (id=381983) [details]
> PATCH: fix gthumb-importer script to properly identify gvfs gphoto2 mounts
> 
> The way the gthumb-importer script identifies gvfs gphoto2 mounts does not (no
> longer) work, this causes gthumb-importer to show an error (except for mass
> storage cams) that the device is busy, making photo importing not work.
> 
> Note:
> 
> 1) this affects both rawhide and F-12, please also issue an F-12 update,
> as currently this makes it very hard for people to use PTP still cams with
> Fedora.
> 
> 2) I also changed the unmount command to only unmount the gvfs mount in
> question
> instead of unmounting all gvfs gphoto2 mounts  

Patch looks good to me - thanks for working on this Hans!

(Behdad is the maintainer so I'll let you guys sort out the rest - just replying because I wrote the original importing code - before we started passing POSIX paths instead of GIO URIs - looks like it broken when that changed)

Dunno how this got reassigned to 0xFFFF... reassigning back to gthumb.

Hans, just go ahead and build this. I know for a fact that Behdad won't mind.

Note that rawhide gthumb needs to be handled differently as it's a completely new codebase as of gthumb 2.11.1. In particular this new codebase is using GIO and thus gvfsd-gphoto2. There's still some bugs to be shaken out, but I'm working with upstream on this - see

 https://bugzilla.gnome.org/show_bug.cgi?id=597410

Thanks,
David

Thanks Hans.  In fact, feel free to take over maintainership if you like.  Same about eog.

Ok,

I'll prepare an F-12 update with the fixed script, and leave devel alone based on
comment #5.

However fixing gthumb-importer is not going to help people, as gvfs bug 552842 gets in the way (David can you please review, it is a really trivial patch, I'll add a comment explaining it there). The problem is that bug 552842 causes gvfsd-gphoto2 to no properly unref the libgphoto2 camera object on unmount, which causes the usbfs device node to stay open (until gvfsd exits, which it does after circa a second).

Now I could add a sleep to the gthumb-importer script to work around bug 552842, but that is just too ugly for words, esp. as there is a very clean patch for bug 552842 attached there.

(In reply to comment #6)
> Thanks Hans.  In fact, feel free to take over maintainership if you like.  Same
> about eog.  

Erm, I have my hands plenty full as is atm, but I wouldn't mind becoming a co-maintainer and committing fixes for things I hit every now and then. I'm currently doing a lot of testing with still cams, as I'm trying to get dual mode
camera's (which can be used as both a still cam and a webcam) to work properly for F-13.

Regards,

Hans

*** Bug 540039 has been marked as a duplicate of this bug. ***

*** Bug 182039 has been marked as a duplicate of this bug. ***

Created attachment 382465 [details]
new gthumb-importer script

Here is a new version of the gthumb-importer script with 2 changes:

1) The way how the detection if the passed in path is a gvfs gphoto2 share
   changed, so that it will work even when the share is not mounted.

2) When launched on a gphoto2 share (hence the detection change), check if
   gthumb-importer is already running and if it is don't start a second time.

   This is needed because with multi head ptp camera's gthumb-importer
   gets launched twice by nautilus, and the second version will fail with a
   device in use error. This is also the reason why the gvfs gphoto2 share
   detection is changed, so that the second started gthumb-importer (at which
   time the first one has unmounted the share already), can still see it is
   being launched on a gphoto2 share.

Also see bug 553580 for the multi head camera problem.

Hans, you might want to check whether Bug 533691 is also a duplicate of this bug here. Marking 533691 and 540039 duplicates of this bug would IMHO also warrant an increase in priority and/or severity of this bug here, as the consequences of this bug outlined there cause a lot of pain and discomfort to users.

(In reply to comment #11)
> Hans, you might want to check whether Bug 533691 is also a duplicate of this
> bug here. Marking 533691 and 540039 duplicates of this bug would IMHO also
> warrant an increase in priority and/or severity of this bug here, as the
> consequences of this bug outlined there cause a lot of pain and discomfort to
> users.  

Peter,

I'm not sure if bug 533691 is a duplicate (which is why I didn't mark it as such). To see if your issue (which I believe is more this bug then bug 533691) is fixed, download the attached gthumb-importer script and replace /usr/bin/gthumb-importer with it (be sure it has executable rights). Also edit the new script and put "sleep 2" directly after the gvfs-unmount command to work around bug 552842 (which I'm also working on fixing).

That should hopefully fix things for you,

Regards,

Hans

I reported this also as bug 553934 (I must be useless at using bugzilla search!) which has been moved to Rawhide as 'unlikely to be fixed in F12'.  Fair enough given changes to gThumb, but F13 too far off and have non computer literate users so must find a workaround in the short term so tried your new script Hans -including the sleep.

It appears not to get invoked.  I added an extra echo to /tmp/log at the top to check and it's not happening, whereas it does happen if I run manually.  Is there somewhere I can check the configuration to see how gthumb is getting invoked as it seems it is not currently via gthumb-importer in my case?

Thanks,
Mike

(In reply to comment #13)
> I reported this also as bug 553934 (I must be useless at using bugzilla
> search!) which has been moved to Rawhide as 'unlikely to be fixed in F12'. 
> Fair enough given changes to gThumb, but F13 too far off and have non computer
> literate users so must find a workaround in the short term so tried your new
> script Hans -including the sleep.
> 
> It appears not to get invoked.  I added an extra echo to /tmp/log at the top to
> check and it's not happening, whereas it does happen if I run manually.  Is
> there somewhere I can check the configuration to see how gthumb is getting
> invoked as it seems it is not currently via gthumb-importer in my case?
> 
> Thanks,
> Mike    

Hmm, so you are saying that gthumb does pop up in photo import mode when you plug in the camera, but the /usr/bin/gthumb-importer script does not get run when that happens ?

(In reply to comment #14)

Yes - strange as it may seem that is exactly what I'm saying.  So I have been hunting around in gconf, my home directory and /etc to work out how the trigger is set up and what it's set to.  Can't find it, or even what seems like appropriate documentation to read.

What's more - although running the gthumb-importer from the command line does invoke my extra log line, it doesn't start gthumb in a way that gets round the bug: I still get the error reported from the library.  I messed around with that last night and on one occasion _did_ get gthumb up without the lock problem and offering to import the photos.  Can I reproduce it?  No of course not.  Some combination of forcing the unmount and time delay I suppose. Will try again later.

gthumb-2.10.11-7.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/gthumb-2.10.11-7.fc12

gthumb-2.10.11-7.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gthumb'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0609

The update does not fix the problem for me. It is even worse: Before I got the dialog where I could choose what to do with the newly connected camera. Now I do not even get this dialog. Hence, except of the icon on the Desktop, there is no visible trace of connecting the camera. 

Moreover, looking on the gnome-import script, I do not understand the modified version. Specially the regular expression "$1" =~ "$HOME/.gvfs/gphoto2" seems to be strange since I have:

~ $  ls ~/.gvfs/
připojení gphoto2 na usb%3A001,005

gthumb-2.10.11-8.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/gthumb-2.10.11-8.fc12

(In reply to comment #18)
> The update does not fix the problem for me. It is even worse: Before I got the
> dialog where I could choose what to do with the newly connected camera. Now I
> do not even get this dialog.

The gthumb-importer script does not get invoked before this dialog. You are most
likely not getting this dialog anymore because you checked the don't ask this
again dialog.

Try creating a new (test) user and testing there.

> Hence, except of the icon on the Desktop, there is
> no visible trace of connecting the camera. 
> 
> Moreover, looking on the gnome-import script, I do not understand the modified
> version. Specially the regular expression "$1" =~ "$HOME/.gvfs/gphoto2" seems
> to be strange since I have:
> 
> ~ $  ls ~/.gvfs/
> připojení gphoto2 na usb%3A001,005    

Ah, the name of the mount is a translated string, I did not know that, a new update fixing this has just been posted.

Thanks & Regards,

Hans

gthumb-2.10.11-8.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gthumb'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0738

gthumb-2.10.11-7.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

gthumb-2.10.11-8.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Hi,

I using gthumb-2.10.11-8.fc12.x86_64 and I have exactly the same problem as described here and in bug 533691. Any help would be appreciated.

Thanks,
Enrique

Yes, this should be marked a duplicate of bug 533691 (and bug 182039). A solution is given there!

(In reply to comment #25)
> Yes, this should be marked a duplicate of bug 533691 (and bug 182039). A
> solution is given there!    

Erm, yes and no. There were 2 issues, our unmount gvfs mount for ptp and
proprietary protocols script was buggy, *and* we had 2 desktop files, one of which was wrong. So we really had 2 issues.