Bug 688836 - Can't connect to mtp device with mtp-tools scripts.
Can't connect to mtp device with mtp-tools scripts.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libmtp (Show other bugs)
14
x86_64 Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Linus Walleij
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-18 03:27 EDT by Gerard Fernandes
Modified: 2011-07-02 15:26 EDT (History)
1 user (show)

See Also:
Fixed In Version: libmtp-1.0.6-3.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-02 15:26:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Gerard Fernandes 2011-03-18 03:27:01 EDT
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:
Comment 1 Linus Walleij 2011-03-31 18:04:53 EDT
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.
Comment 2 Gerard Fernandes 2011-04-01 16:57:55 EDT
>>  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?
Comment 3 Linus Walleij 2011-04-02 06:28:38 EDT
(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.
Comment 4 Gerard Fernandes 2011-04-04 01:14:28 EDT
>>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.
Comment 5 Gerard Fernandes 2011-04-04 01:17:10 EDT
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."
Comment 6 Linus Walleij 2011-04-25 05:48:55 EDT
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....
Comment 7 Linus Walleij 2011-04-25 05:49:26 EDT
(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?
Comment 8 Fedora Update System 2011-06-23 14:25:36 EDT
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
Comment 9 Fedora Update System 2011-06-23 23:21:26 EDT
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).
Comment 10 Gerard Fernandes 2011-06-24 01:16:33 EDT
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... :)
Comment 11 Linus Walleij 2011-06-26 08:16:58 EDT
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 :-)
Comment 12 Fedora Update System 2011-07-02 15:26:24 EDT
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.

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