Description of problem: Can't connect to mtp device with mtp-tools scripts. Version-Release number of selected component (if applicable): Name : libmtp Arch : i686 Version : 1.0.3 Release : 7.fc14 How reproducible: Always Steps to Reproduce: 1. Make sure you have libmtp (usually installed by default) 2. Install the mtp-tools scripts 2.a. Connect your MTP device (a Cowon D2 in this case) 2.b. Run mtp-detect - note that it hangs. 2.c. Run RhythmBox. Note that it shows your device as a Cowon D2 and allows browsing it. Close RhythmBox. 2.d. Run mtp-detect - note that it correctly detects your device. Obviously RhythmBox had something to do with this! 3. Install pymtp Name : python-pymtp Arch : x86_64 Version : 0.0.4 Release : 1.fc14 4. Connect your MTP device (a Cowon D2 in this case) 5. Run mtp-detect - note that it hangs. 6. Open RhythmBox. Note that it doesn't detect your device anymore - just shows Unknown Device. Close RhythmBox. 7. Run mtp-detect. Note that it hangs. Actual results: mtp-detect does not reliably detect a device. Before isntalling pymtp, running RhythmBox had an effect. After installing pymtp, even this stopped working. Can't imagine why! Expected results: mtp-detect (and all mtp-tools scripts) should always reliably connect to an mtp device when attached. It should not require running RhythmBox to initialise a device correctly. It should not be affected by installing pymtp. Additional info:
I think this is a shortcoming in your device. See the following snippet from libmtp:s README: * Generic MTP/PTP disconnect misbehaviour: we have noticed that Windows Media Player apparently never close the session to an MTP device. There is a daemon in Windows that "hooks" the device by opening a PTP session to any MTP device, whenever it is plugged in. This daemon proxies any subsequent transactions to/from the device and will never close the session, thus Windows simply does not close sessions at all. Typical sign of this illness: broken pipes on closing sessions, on the main transfer pipes(s) or the interrupt pipe: Closing session usb_clear_halt() on INTERRUPT endpoint: Broken pipe OK. This means that device manufacturers doesn't notice any problems with devices that do not correctly handle closing PTP/MTP sessions, since Windows never do it. The proper way of closing a session in Windows is to unplug the device, simply put. Since libmtp actually tries to close sessions, some devices may fail since the close session functionality has never been properly tested, and "it works with Windows" is sort of the testing criteria at some companies. You can get Windows-like behaviour on Linux by running a HAL-aware libmtp GUI client like Rhythmbox or Gnomad2, which will "hook" the device when you plug it in, and "release" it if you unplug it. If this bug in your device annoys you, contact your device manufacturer and ask them to test their product with some libmtp program.
>> You can get Windows-like behaviour on Linux by running a HAL-aware libmtp GUI client like Rhythmbox or Gnomad2, which will "hook" the device when you plug it in, and "release" it if you unplug it. Thats not the point, is it? If RhythmBox can "Do The Right Thing"(tm), shouldn't libmtp itself Do The Right Thing in the first place? >> If this bug in your device annoys you, contact your device manufacturer and ask them to test their product with some libmtp program And if that's the way GNU/Linux is going forwards, shall we tell the Nouveau people to ask nVidia to test their graphics cards with the Nouveau drivers? The bottom-line is this: it's impossible to write any "nice" GUI tools (e.g. for editing play-lists) without a reliable foundation. Ever notice the lack of _reliable_ MTP clients in GNU/Linux? Perhaps this is why Song-Bird gave up?
(In reply to comment #2) > Thats not the point, is it? If RhythmBox can "Do The Right Thing"(tm), > shouldn't libmtp itself Do The Right Thing in the first place? The point is that the hardware cannot do the right thing. > And if that's the way GNU/Linux is going forwards, shall we tell the Nouveau > people to ask nVidia to test their graphics cards with the Nouveau drivers? I am not the community, you are. Suggest a solution... > The bottom-line is this: it's impossible to write any "nice" GUI tools (e.g. > for editing play-lists) without a reliable foundation. Ever notice the lack of > _reliable_ MTP clients in GNU/Linux? Perhaps this is why Song-Bird gave up? GUI tools, as explained is not any problem at all, as long as one GUI tool is used execlusively, like Windows Media Player, which is what everyone use on Windows.
>>I am not the community, you are. Suggest a solution... The solution is to make libmtp reliable - at least 80% of the time. It isn't reliable at the moment. In one release of Fedora it works, in the next it breaks. Of course this is no fault of Fedora - it is the way libmtp is. And that is what this bug report is about. Note that the libmtp documentation also mentions something about setting the vendor/device string in a .h file for "force"ing the device to be connected (eg by force-closing all possibly open connections to the device). Perhaps this will work. However, if that is the case, it should be also exposed as an API so that it can be called by client programs to "force" connect the current device. And taking this further, it should be a flag in the API so that a client program can ask for a "force" connection on the connect API. >>GUI tools, as explained is not any problem at all, as long as one GUI >>tool is used execlusively, like Windows Media Player, which is what >>everyone use on Windows. GUI tools _are_ a problem - of course they will be as long as the foundation they rely on is unreliable. See Bug 679724 also reported by me. The same lack of reliability can be seen with GNomad-2. Sometimes it works, other times it doesn't. On the other hand, in Windows, connection _always_ works.
See: http://libmtp.sourceforge.net/newdevice.php - the hacking your device section, quoted below: "The most common flag that needs to be set is the DEVICE_FLAG_UNLOAD_DRIVER that detach any Linux kernel drivers that may have attached to the device making MTP access impossible."
Yes, these are correct observations, I think you need to work with the upstream project and help them improving libmtp so it becomes the reliable library you want. What is needed is patches to libmtp, and I cannot make any such patches without being able to test it on a problematic device. And I don't have one. I only have the Creative Zen Micro, which works *flawlessly* with libmtp tools and Rhythmbox. Donating problematic hardware to the libmtp developers is one way to solve this, they have no resources whatsoever for interoperability testing....
(In reply to comment #5) > See: http://libmtp.sourceforge.net/newdevice.php - the hacking your device > section, quoted below: > > "The most common flag that needs to be set is the DEVICE_FLAG_UNLOAD_DRIVER > that detach any Linux kernel drivers that may have attached to the device > making MTP access impossible." Have you tested this with your device to see if it solves your problem?
libmtp-1.0.6-3.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/libmtp-1.0.6-3.fc14
Package libmtp-1.0.6-3.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libmtp-1.0.6-3.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/libmtp-1.0.6-3.fc14 then log in and leave karma (feedback).
Is it possible to get this version of libmtp for F-15? I upgraded both my laptops to F-15 soon after it was released :( so don't have a F-14 installation anymore... You can't really blame me - Gnome-3 on F-15 is so coooooooool... :)
I've submitted the same update to F-15, so it's on updates testing. The real libmtp 1.1.0 can only be included in rawhide right now due to interface bump, upgrading in present distributions would be very disruptive. And I agree about GNOME3 :-)
libmtp-1.0.6-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.