[clug] MTP and Python - any ideas?

Chris Smart clug at christophersmart.com
Sun May 8 06:19:19 UTC 2016


On Thu, May 05, 2016 at 07:30:02AM +1000, Paul Wayper wrote:
>On 02/05/16 21:20, Chris Smart wrote:
>> On Mon, May 02, 2016 at 08:41:00PM +1000, Paul Wayper wrote:
>>> Hi all,
>>>
>>> Is anyone familiar with using libmtp to interface with MTP devices?  I'm
>>> trying to write a program to get some information from my phone, but while the
>>> kernel's usbfs module seems quiet happy to see the phone's file systems and
>>> MATE's file manager can browse the device, my simple "get the device name and
>>> free space" program doesn't get much further than the attempting to connect.
>>>
>>
>> [snip]
>>
>>>
>>> Any ideas?
>>>
>>
>> This could be because your phone is already in use by nautilus. Can you
>> try ejecting it from nautilus and re-run your program?
>
>One of the points about MTP is that it allows multiple programs to talk to the
>storage on the device, as well as the device itself to see its own storage.
>That's why Nautilus and Rhythmbox can both see the music on your phone at the
>same time.

I could be wrong, but I think that this is because GNOME is providing the same
interface via a GVFS mount that both nautilus and rhythmbox use.

If you eject your phone from nautilus and then open rhythmbox it won't
even see your device. Mount it in nautilus and it will appear in
rhythmbox. Unmount it in nautilus and it will disappear from rhythmbox.

You can see your GVFS mount at somewhere like:
/run/user/1000/gvfs/

E.g. my phone is at:
/run/user/1000/gvfs/mtp\:host\=%5Busb%3A001%2C016%5D/Internal\ shared\
storage/

You can even rsync files off the device from that location if you want
to.

MTP works at the file, not block, level and is not parallelised, so a new
command must wait until the previous one completes.

If you were to open a second interface to the device, you may find that
access is not as seamless.

For example, I can't access my phone in shotwell when it's mounted in
nautilus until I eject it. I expect you would have a similar experience,
but maybe not.

To backup my claim, I kicked off an rsync of my photos from the gvfs
directory:

[15:54 chris ~]$ rsync -Pr
/run/user/1000/gvfs/mtp\:host\=%5Busb%3A001%2C016%5D/Internal\ shared\
storage/DCIM /tmp/

Then in another window I ran mtp-detect and I got this error:

[15:54 chris ~]$ mtp-detect
libmtp version: 1.1.11

Listing raw device(s)
Device 0 (VID=18d1 and PID=4ee1) is a Google Inc (for LG
Electronics/Samsung) Nexus 4/5/7/10 (MTP).
   Found 1 device(s):
      Google Inc (for LG Electronics/Samsung): Nexus 4/5/7/10 (MTP)
      (18d1:4ee1) @ bus 1, dev 16
      Attempting to connect device(s)
      ignoring libusb_claim_interface() = -6PTP_ERROR_IO: failed to open
      session, trying again after resetting USB interface
      LIBMTP libusb: Attempt to reset device
      ignoring libusb_claim_interface() = -6LIBMTP PANIC: failed to open
      session on second attempt
      Unable to open raw device 0
      OK.

I repeated the mtp-detect command three times and then, it worked! However,
back at my rsync terminal, the command failed and I got this:

rsync warning: some files vanished before they could be transferred
(code 24) at main.c(1165) [sender=3.1.1]

Nautilus still thinks it's mounted, but I can no-longer ls directories
at the gvfs mount point. The process is stuck in uninterruptable sleep
(D+) and I can't kill it:

[15:54 chris ~]$ ls
/run/user/1980/gvfs/mtp\:host\=%5Busb%3A001%2C016%5D/Internal\ shared\
storage/bluetooth/

I expect you could try this and get a similar result on your machine.

As I mentioned in my original reply, I got the same error as you when
trying your script when my phone was mounted in nautilus.

When I ejected it from nautilus, the script started mostly working, but
it was a bit inconsistent.

When the phone was mounted in nautilus, the mtp-detect program would fail
but it was often able to reset the USB (built into the program) and then
was able to access the device upon a second try.

It's also possible that libmtp has some bugs with your device, though.

I don't know whether you even bothered to give my suggestion a try or
not, you don't say, but I did spend some time with your program to see
if I could get it to work before I posted my reply.

-c



More information about the linux mailing list