$ mtpfs /tmp/android Listing raw device(s) Device 0 (VID=04e8 and PID=6860) is a Samsung GT-P7310/P7510/N7000/I9100/Galaxy Tab 7.7/10.1/S2/Nexus/Note. Found 1 device(s): Samsung: GT-P7310/P7510/N7000/I9100/Galaxy Tab 7.7/10.1/S2/Nexus/Note (04e8:6860) @ bus 1, dev 12 Attempting to connect device PTP_ERROR_IO: failed to open session, trying again after resetting USB interface LIBMTP libusb: Attempt to reset device LIBMTP PANIC: failed to open session on second attempt Unable to open raw device 0 $ dmesg output: [165142.718035] usb 1-3: new high-speed USB device number 12 using ehci_hcd [165142.834852] usb 1-3: New USB device found, idVendor=04e8, idProduct=6860 [165142.834858] usb 1-3: New USB device strings: Mfr=2, Product=3, SerialNumber=4 [165142.834863] usb 1-3: Product: SAMSUNG_Android_SCH-I535 [165142.834867] usb 1-3: Manufacturer: SAMSUNG [165142.834870] usb 1-3: SerialNumber: 3a03601b [165216.336041] usb 1-3: reset high-speed USB device number 12 using ehci_hcd [165438.321044] usb 1-3: reset high-speed USB device number 12 using ehci_hcd I ejected the device in GNOME before attempting to use mtpfs on it, so I don't think gphoto2 is interfering.
When you try this, make sure the screen is unlocked on the device. Android do not allow you to connect to a device with locked screen so as to avoid MTP being used as a backdoor. Pls verify that screen is unlocked when testing.
Yes, confirmed, screen is not locked. libmtp still hangs.
I am using a similar device so I'm a bit confused :-/ What I do is start the program "gnomad2" (wrote it myself that's why...) and plug in the device when the program is running. This always works. Rhytmbox also mostly works the same way: program needs to be up before connecting the device. Can you test if this works? In that case we need to reassign the bug to mtpfs as the library works in other contexts. Please also try the command-line programs like "mtp-detect" and "mtp-files" from the package "libmtp-examples" and see what happens. They usually need to be run shortly after the device was plugged in, since Androids seem to get "numb" if you don't use them quickly enough.
(In reply to comment #3) > I am using a similar device so I'm a bit confused :-/ Define "similar". Every new device that comes out has slightly different tweaks in it. And are you using the vendor-supplied image, or a CyanogenMod image or something like that? Are you sure the device you're using is being talked to with MTP rather than USB Mass Storage? For some reason Verizon Wireless and/or Samsung decided to disable USB Mass Storage in the Verizon Wireless version of the Galaxy S III, so I'm stuck using MTP, which really doesn't work as well. > What I do is start the program "gnomad2" (wrote it myself that's why...) and > plug in the device when the program is running. This always works. Rhytmbox > also mostly works the same way: program needs to be up before connecting the > device. Gnomad2 has the same problem for me. Here's what it reports on the console when I start it up and then plug in the S III: $ gnomad2 PDE device NULL. add event for /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3 (bd0a)vendor = 4e8, model = 6860, bus = 1, device = b device is MTP or libnjb compliant PDE device NULL. Unhooked, hook this device! PDE device NULL. Device 0 (VID=04e8 and PID=6860) is a Samsung GT-P7310/P7510/N7000/I9100/Galaxy Tab 7.7/10.1/S2/Nexus/Note. PTP_ERROR_IO: failed to open session, trying again after resetting USB interface LIBMTP libusb: Attempt to reset device > Please also try the command-line programs like "mtp-detect" and "mtp-files" > from the package "libmtp-examples" and see what happens. They usually need > to be run shortly after the device was plugged in, since Androids seem to > get "numb" if you don't use them quickly enough. mtp-detect has the same problem.
Yes I know all about different devices (having authored libmtp) but I had the impression that most recent Samsungs were using similar MTP stacks and not all that deviant from each other, that's why I'm a bit confused. In essence what you're saying is that I have no chance to duplicate the behaviour unless I get a device like this and sadly my budget is $0. I'd suggest cloning libmtp from git and start hacking, the INSTALL file gives all details on how to proceed altering LD_LIBRARY_PATH to use the fresh-compiled version. git clone git://libmtp.git.sourceforge.net/gitroot/libmtp/libmtp
No need to be snarky, I didn't know you were the libmtp author. I'm doing the best I can to give you as much information as possible. I've managed to get it to work intermittently by disabling gvfs-gphoto2, but only intermittently (so I'm not actually sure that disabling gvfs-gphoto2 was relevant). I got mtp-detect to work once, but not a second time, even after unplugging and replugging the device and making sure it wasn't locked. I got mtpfs to work once, but it can only see directories -- no files -- on the mounted device. When mtp-detect or mtpfs works, it takes a long time, on the order of a minute, to detect the device. Is it possible that this is related to the amount of data I have on the device? I have thousands of music files. Is it possible that they all need to be enumerated at connect-time, and that's taking a long time, and libmtp isn't waiting long enough? Is there a timeout setting I can increase? Is there a debug flag or something that I can pass to mtp-detect to get it to print out more verbose information about what it's doing when it's trying to connect to the device?
On the possible intervening gvfs you might be onto something, I think it is possible to configure which application takes precedence when a device is plugged in. I somehow managed to get gnomad2 to hog it first, but this definately needs looking into, maybe a more precise bug can be filed agains gvfs-gphoto2? Yes the amount of data is a factor. Have you tried the command mtp-filetree? It uses the new per-item lookup calls that are better suited to match the way Google implemented their MTP stack. Another program that reportedly works better with MTP devices is go-mtpfs, I don't think this program is yet in Fedora, but maybe you can compile it and test. Atleast some of the MTP example programs can be supplied with the -d flag to print verbose debug info.
Thanks for your help. I understand what's going on much better now. I'm not really sure there's any way for Fedora or libmtp to do any better than it's doing. Let me explain what I've learned... The README for libmtp mentions, and you mentioned as well, that some Samsung devices go "numb" if you don't connect to them within a short time after they are plugged in. The README file said 7 seconds, I believe, and I was connecting well within that range. However, it turns out that the timeout for my SIII appears to be much less, like around 2-3 seconds. If I wait any longer than that after plugging in the USB cable before connecting with libmtp, it doesn't work. I was able to connect reliably with libmtp by (a) killing gvfs-gphoto2-volume-monitor and (b) running the libmtp command pretty much immediately after plugging in the device. One time I managed to run the command _too_ quickly, probably before USB had settled, but that wasn't the norm. Mtp-detect, mtp-filetree, and mtpfs all read all of the file metadata from the device before returning, so even when they connect successfully, they take a very long time on a device with lots of files, and therefore it could appear that they are hanging. I'm not sure if there is a way to improve this behavior, either by eliminating the need for them to read everything up-front, or by giving some sort of progress indication of what they're doing so it doesn't look like they're hanging. Even when I connect successfully with mtpfs, it still only sees directories, not files. I am going to file a separate mtpfs bug about this. The go-mtpfs tool you referenced works great and is exactly what I need! Thanks again.
Hm, how do you actively kill gvfs-gphoto2-volume-monitor? Maybe I should look into some way of hooking Gnomad2 and the Rhytmbox plugin into the volume monitor as well. Atleast there must be a proper way to disable the gphoto2 plugin. The ideal is if the programs are run right after insertion, after udev has signalled to the app that the device is there. Probably the mtp-* examples should be enhanced with some rudimentary udev support so they display something like "waiting for device to be plugged in" if no device is detected. I'm a bit puzzled about mtp-filetree being slow, it is explicitly uncached, so it does not read in all files on start. Then it prints out files as it traverses the file system. This is a bit odd... PS sorry for my grumpiness earlier, this was more a sign of despair.
(In reply to comment #9) > Hm, how do you actively kill gvfs-gphoto2-volume-monitor? Just do "ps aux | grep gphoto2" to find the PID and send it a kill signal. Perhaps there's a better way to do it, but that works. :-)
Does: pkill gvfs-gphoto2-volume-monitor && mtp-detect work nicely?
You can't do it all at once like that, because you need to kill volume-monitor, then plug in the phone, then run the mtp-detect command within a couple seconds of plugging in the phone, or the phone goes numb. The timing is key. So you need to do it as two separate commands, separated by the physical act of plugging in the phone. You need to kill volume-monitor before you plug in the phone because otherwise it might try to connect to it and mess things up.
http://forums.fedoraforum.org/showthread.php?t=284741 jmtpfs works like a charm on my Samsung Galaxy S III.
I conclude, since jmtpfs is working that this is atleast not a libmtp bug & closing...
I can see similar behaviour with libmtp. At first try, I can do LIBMTP_Open_Raw_Device_Uncached() and work with a Nexus 5. Second try, I am not successful. libmtp waits for 1 minute and then issues libusb_reset(), which makes Nexus 5 work with the library. In sources, you state, the reset is for bad applications, which do not call LIBMTP_Release_Device. I call this every time, I am done communicating with the phone. The same situation is with Nexus 7 or Galaxy Nexus. Can you provide any valuable help with this?
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days