Talk:Media Transfer Protocol

message: This program is not compiling well with the instructions given by the author. After compiling like it should be it does *not* work well. It does all kind of strange things but not the right thing. This definitly is alpha code. I am writing about working with it with the Samsung YP-U3. Should this link stay on this page? Is it not better to remove it here and move it to a programmers wiki?  —Preceding unsigned comment added by 89.220.236.161 (talk) 12:34, 6 May 2008 (UTC)
thread_title:  MTPSync 

message: The recently added text looks like it was copied in from some source, a source which should be verified as being compliant with the GFDL I will consider reverting these addition unless the anonymous submitter stands up. Nixdorf 11:31, 15 May 2006 (UTC)
thread_title:  Possible plagiarism 

message: I have GoGear, and it works like a classic USB Storage device, not in MTP mode.
--89.79.216.123 (talk) 21:11, 25 August 2008 (UTC)
thread_title:  Philips GoGear 

message: ::"For example on Windows XP, drag and drop is only allowed through Windows Explorer when the Windows Media Player synch is running."
:That is erroneous for me.  With both a Sansa Clip and a Samsung YP-S5J in MTP mode, i'm able to drag drop files in them without ever using Windows Media Player (wich i wouldn't never want to use anyway). But maybe it's because i'm on XP SP3 ? TulipVorlax (talk) 08:52, 16 December 2008 (UTC)
replies: text: It's a service that's installed at the same time as WMP. It doesn't require WMP to be open to work 86.146.212.64 (talk) 19:46, 11 November 2014 (UTC)
thread_title:  Erroneous statement ? 

message: I fixed up a few bits and pieces in this article, since some of it seemed pretty strange to me.
Intro: Changed 'movie files' to 'media files', added mention of PDA support. Removed 'no known devices' bit, because it's been over a year since July 2008 and it's probably (hopefully) inaccurate by now.
Advantages: Removed sentence on MTP being able to store more files than MSC, file storage limits are filesystem-related, not MSC-related. I think MTP is usually implemented on top of a normal filesystem, so the assertation that space is saved by MTP is probably wrong, but I think I've seen that mentioned as an advantage somewhere so I put a citation needed on it.
Drawbacks:
Removed section on device-specific file management software being needed (it isn't), removed section on proprietary cables being needed (they aren't), removed section on motivations (it's unsourced, and fairly NPOV as it only gives 'bad' reasons for implementing MTP), removed bit on being unable to alter keywords (device-specific, according to the USB standard), removed ancillary data section (not related to MTP, and doesn't make much sense. Why would a media application support arbitrary file transfer?). Also changed 'modification of contents', since it was a bit incorrect (the file must be deleted and reuploaded, though I think there may be a way around this in the standard which I missed). The file is transfered in 64 byte packets (a limitation of the PTP standard, though some MTP implementations ignore this and use a packet size of 512. Windows only appears to allow this for some devices, I think it's related to whether you have an MTP OS descriptor), and interfacing with a normal filesystem really isn't that difficult.
Windows MTP support: Should this even be here? I changed the Windows 7 line to present tense and added a citation needed, since I don't know for certain where the appropriate device service definition would be (though I think I've seen mention of sensors in the MTP simulator configuration files, which seems to contain a list of most or all device service GUIDs), and I'm sure there was mention of this in a WinHEC powerpoint somewhere
Support for legacy Windows versions: Ripped out the how-to section, and the MTP porting kit description too.
Deficiencies in the Windows implementation: I removed it, MTP isn't a Windows-specific protocol. There's no citations for most issues, and some redundant information about the MTP porting kit too.
Synchronization: I ripped this out, I'd say the whole point of MTP is to allow easy synchronization of metadata. As for autosync, the WMP extention for AutoSync just adds a 'changed content' operation to notify the initiator about new content added outside of MTP (ie audio/video recordings) IIRC, and I'm not sure if that's even needed to enable automatic synchronization or not.
PlaysForSure: Should probably be moved into the main playsforsure article, but I'll leave it where it is for now.
Implementations: Removed 'native' from the 'FastPictureViewer Professional' entry, since it probably uses WPD to access the device; unless it actually implements it's own version of the MTP driver (in which case, citation needed).
Hopefully this makes the article a bit clearer -- Fanta2 (talk) 13:42, 8 November 2009 (UTC)
thread_title:  Fixup 

message: There is no KIO for MTP support, every KDE application implements it in their own way. Also Dolphin cannot browse MTP devices at all.
https://bugs.kde.org/show_bug.cgi?id=181968  — Preceding unsigned comment added by Sergei.Stolyarov (talk • contribs) 05:12, 10 January 2012 (UTC)
replies: text: That bug is now marked "resolved fixed", with references to an "MTP KIO", as of 2013-01-12, so presumably the comment above is now out of date. Guy Harris (talk) 19:26, 16 October 2015 (UTC)
thread_title:  MTP and KDE 

message: I have noticed in Windows 7 at least, that there are a number of restrictions to MTP (and PTP) that do not apply with UMS.
* Windows Explorer can not display thumbnail images for files
* Files can not be dragged-and-dropped from Windows Explorer onto other program windows (although you can drag and drop WITHIN Windows Explorer)
* Multiple files can not be selected in the OpenFile dialogs - you are only allowed to select-and-OK one file at a time. If you try to select a second file you get an error box saying "Cannot open multiple items from this location. Try selecting a single item instead"
For the details see:
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/db592cbd-e3cb-4828-9cfe-f0826c4f925a
It isn't clear how much of these restrictions are caused by Windows rather than MTP/PTP, but there are none of these propblems if you can switch the external device to use UMS instead.
Should these restrictions be added to the list of limitations on the MTP and PTP pages?  — Preceding unsigned comment added by 87.194.105.103 (talk) 13:39, 19 March 2013 (UTC)
replies: text: To explain some of limitations... Thumbnails _can_ be displayed (and are) but since the file has to be transferred to the PC to generate the thumb, and MTP only allows one operation at a time (list directory, get file) it can take a very long time. Re: Drag/Drop: Behind the scenes, this works by sending the path of the file to the target application. MTP has no drive letter/traditional paths so unless the app is expecting an MTP file, it won't be able to handle it. Explorer does handle MTP files so is a valid drop target. Last one is similar to the first... MTP only allows a single operation at a time, so this is a protocol limitation. And yes, it sucks badly 86.146.212.64 (talk) 19:50, 11 November 2014 (UTC)
thread_title:  MTP problems in windows 

message: I removed this section with the comment: Revert -- that is not an adequate reference. Furthermore, it's a flaw in Windows, not MTP. Furthermore, it's not a flaw, because C:\Users\<user> IS a secure location.
User:60.242.152.37 responded: Then the heading should be "Windows MTP data security flaw" I will change this. This fault is user verifiable. Try a second login and view other the users file path - that path is not secured on any version of windows that I've used.
He is wrong. See here, for example. If he is able to view the users folder of another user, that is because his current user is an administrator, or perhaps he has granted cross-account access at some time in the past. – Smyth\talk 14:45, 20 April 2013 (UTC)
replies: text: "He is wrong" = Smyth.  Does not stand up to scrutiny.  You invalidated your own statement by providing exception that demonstrates the how the very security flaw works.  Yes you can restrict an "individual" non administrator login from viewing other user file paths and other parts of windows but the data copies left behind are not secure from administrator login.  A company may have a "visitors" login, it will "collect" any file opened from a connected MTP configured device.  The data on the MTP device is not secured.  This represents a breach of copyright and privacy against the user of the MTP device.  — Preceding unsigned comment added by 60.242.152.37 (talk) 01:13, 21 April 2013 (UTC)

text: The generic windows install is admin, the average user, and the average business operator does understand that the MTP implementation on windows strips data from the MTP device.  The data security is still valid for MTP on windows.  Playing your music files would breach copyright if someone else accessed the files later.  It is not informed to anyone that this is happening.  You may not keep anything person on your phone but the millions of users for whom their devices are personal, are.  They may want to know that the issue exists.  The "citation needed", simple user testing by anyone. — Preceding unsigned comment added by 60.242.152.37 (talk)
A little history, PTP was orignally a hack of the USB implementation that saved a camera company money because they didn't have to implement a full USB stack on the camera (USB was pretty expensive then). The implementation had a side effect in that users couldn't use the full USB stack of features and so it acted like a limited DRM system. Microsoft took this side effect ( sic: feature ) further and gave us MTP. The resulting system is so restrictive that workarounds are implemented to access a users files/media or any other data they create on the device. As usual with work arounds they come with their own issues.  One of those is that files have to be copied off the device before opening and as a result we have the biggest theft of personal user data the world has ever seen.  — Preceding unsigned comment added by 163.189.7.40 (talk) 03:08, 28 June 2013 (UTC)
thread_title:  Windows "Data security flaw" 

message: User:60.242.152.37 has introduced the word "control" in numerous places in this article. Here is the explanation he left on my talk page:
:The Media transfer protocol controls the transfer of data by overlaying the underlaying transfer method and limiting the full access the underlying transfer system allows.  For example, it does not add to the abilties USB but it does control the access to and functioins of USB, it will not work without the underlying system functions.  It does not "allow" the transfer of files, that is part of the underlying system and is already there, it controls how the data is transfered through the underlying sustem.
:PTP was developed by camera manufactures to save cost by not having to supply a full USB interface.  It allowed access only to those functions the device was capable of.  Microsoft adapted it to control and limit the function of the full USB interface.
:A paraplegic in a wheelchair will benifit from the improved access a wheelchair allows but but for a person who can walk a wheelchair controls and limits where he can go.  MTP is designed to control and limit the access that the underlying system allows.  — Preceding unsigned comment added by 60.242.152.37 (talk) 04:07, 20 April 2013 (UTC)
replies: text: What I'm trying to describe is the functional behaviour of MTP (Not DRM).  MTP does not function without first connecting through the underlying interface.  The MTP implementation at each end then hides the USB (or other) interface and gates off the other functions of the underlying interface, "tunnelling" to MTP components at each end.  The USB connection "allows" the transfer, MTP "controls" it.  The seeminigly simultanious access within the MTP configured device being provided because MTP limits tranfers to one transfer at a time for the MTP device, the device then only sees one incoming/outgoing transfer at a time "allowing" the device to perform other functions, multiple simultanious PC transfers to the MTP device are not allowed.  A user from the PC side must wait until the previous transfer is complete before commencing another, therefore MTP does not provide simultanious access and the access across MTP (through the USB connection) from the PC side is "controlled" by MTP.  — Preceding unsigned comment added by 60.242.152.37 (talk) 02:17, 21 April 2013 (UTC)

text: Maybe because MTP doesn't work without the USB, TCP or Bluetooth interface?  It's not called an MTP interface is it, it's a protocol - a method of communicating within set parameters.  And those parameters are limited by?  Well the interface within which it operates of course.  It blocks and replaces any access to the other parameters available.  The standard interface is still blocked, interupted, controlled by MTP.  USB, TCP or Bluetooth, if it's not using the interface, what is it's protocol limits?  It must first use that interface, or it's own version of the minimum, the very same thing PTP is, a stripped out version of USB.  If MTP expanded on the abilities available then of course it would be "allow"ing the user to do things, the point is that it that the interface it already capable of far more than the MTP allows, therfore MTP controls the interface.  — Preceding unsigned comment added by 60.242.152.37 (talk) 09:53, 27 April 2013 (UTC)
thread_title:  "Control" vs "allow" 

message: "making the unit of managed storage a local file rather than an entire (possibly very large) unit of mass storage at the block level"
When the media were jpeg images, fs blocks might have been adding a lot to the transfer size over USB, but in the context of MTP, "(possibly very large)" wouldn't be accurate.  — Preceding unsigned comment added by 38.99.42.130 (talk) 17:38, 19 July 2013 (UTC)
replies: text: That fragment is not concerned with transfer size, but the vulnerability of exposing the storage at a too basic level. Imagine you were a storage device. As a storage device, you will likely get the blame if the fileystem stored on you becomes corrupt, even if it's the user's fault, which it might well be. The filesystem looks a lot like a house of cards (see binary tree), only with blocks instead of cards. Some filesystem operations, like adding or removing files, will sometimes need to optimize the internals of your cardhouse (rebalance a subtree). As you can imagine, replacing any one card of your cardhouse, if left half-done, will cause your cardhouse to collapse. Now, the mass-storage device protocol works like this: You are cardhouse agnostic; the client manipulates your cardhouse (overwrite blocks) directly, and you must hope you aren't disconnected in a particularly bad half-done state. MTP works more like the client tells you what to do, and you do it — either completely, or you undo it if something unforeseen happens. --84.208.189.151 (talk) 22:48, 14 March 2016 (UTC)
thread_title:  Deceptive (to a non-technical reader) part about block size? 

message: A lot of this article discusses limitations that may or may not be flaws in the Microsoft implementation of MTP. At one time, the argument could be made that it was not practical to talk about Microsoft's implementation vs. the specification as separate things. However, with Android devices using MTP there now exists significant independent support. In particular, the lack of parallelism jumps out at me as being a problem in Windows, or Windows Explorer. I can say from personal experience using go-mtpfs on Linux (written by a Google employee), that this is not true. Now, it could be that go-mtpfs does some caching and queuing tricks - I know it does this to speed up directory listing, for example. The article discusses the Android dio extensions, but is unclear about what "Drawbacks" exist because of shortcomings of the protocol itself and which exist in major implementations (i.e. Windows).
On a more minor, but related note, it seems like discussions of Windows security bugs that happen to involve MTP are largely irrelevant to the article. Like I said, at one time "Microsoft MTP" and "MTP could be said to be one and the same, but with Google's move to MTP, it's harder to say that now. 108.183.217.0 (talk) 21:45, 1 August 2014 (UTC)
thread_title:  Implementation vs. specification 

message: The article describes the MTP Missing Drive Letter problem, which is quite a serious limitation when accessing an Android phone from a Windows computer via USB cable. Please add information about getting around the problem. There seem to limited solutions on the Windows end, such as a plugin for TotalCommander. Solutions from the phone end seem better, such as the free app "MTP-Alternative USB Drive".-73.61.15.208 (talk) 16:56, 21 December 2017 (UTC)
thread_title:  Drive Letter problem 

message: * android.stackexchange.com/questions/46315/not-all-files-are-visible-over-mtp
* droidguiding.com/certain-folders-and-files-missing-in-pc-while-they-are-in-phone-how-to-fix-it/
: "All you need to delete the app cache and data from ‘Media Storage’ and ‘External Storage’ system apps on your phone. All files and folders will appear on the PC then."
When accessing a file system via MTP (Moto E4 And711 USB Win7pc) it may report much greater total content than can actually be seen as individual files: Almost 2GB reported total, only about 600MB seen, over 1GB missing content. Why? Is there some way to find out what files/data is being hidden? (The above two links discuss a similar problem, but in this case clearing app cache and rebooting etc does not help.) Please add relevant info to the article about this issue.-73.61.15.50 (talk) 16:56, 22 December 2017 (UTC)
thread_title:  MTP file data hidden missing 

message: In my experience, MTP sometimes gets stuck transferring files, does not show newly moved/created files and to just “Prepare for copy”, it needs half the time of the copying itself, while mass storage copying starts immediately.
And when it gets stuck, pressing “Cancel” leads to “in progress of cancelling”, which lasts indefinetly. It sounds as absurd to me as “Loading ‘error’ text. Please wait.”. The only thing one can do is physically plug the USB cable out of the phone or PC.
Additionally, MTP can get stuck in a disconnection/reconnection cycle. I left my mobile phone connected to the computer and left. When I came back, the computer greeted me with an avalanche more than 100 udev error messages that have appeared because MTP failed to reconnect to the device that many times. So MTP can flood one's computer with error messages.
Since the beginning, MTP has always been a huge bothersome, headacheful obstacle to me. I know the advantages of it, but it is so unreliable that I despise it. And PTP is no real alternative because it hides all non-photo files.
When trying to access files while something else is already being transferred, it gets unresponsive indefinitely.
MTP is a luxury problem.
I suggest this to be mentioned in the article, but I am asking here if anyone else is familiar with it. –Chanc20190325 (talk) 13:43, 2 June 2019 (UTC)
replies: text: That would need citations from reliable sources for the problems; those citations would presumably indicate whether those problems are problems with the MTP protocol, or just deficiencies/bugs with the implementation on your PC or your phone. Guy Harris (talk) 18:01, 2 June 2019 (UTC)

text: Yeah it is hopeless, the whole article should be about that :p Pretty much never works.  — Preceding unsigned comment added by 180.150.71.154 (talk) 23:36, 24 January 2020 (UTC)
thread_title:  MTP is unreliable and headacheful. Should these annoyances be mentioned? 

message: When initiating a data transfer of thousands of files from an Android OS device, no matter whether big or small files, before the first of those files starts getting transferred, the operating system shows “Preparig to copy files”.
It might take 10 minutes before the first file has been transferred, while on mass storage, file transfer starts immediately.
Sometimes however, it just takes one minute or less, surprisingly. (It tends to take less time after rebooting the device.)
I encourage someone to add a technical explanation to this behaviour. --Handroid7 (talk) 07:10, 1 August 2019 (UTC)
thread_title:  What happens during “prepare to copy files”? (technical explanation) 

message: These issues:
* «The neutrality of this section is disputed.»
* «This section possibly contains original research.»
What needs to be done to resolve them?
; What I think this section should be about
* Saying what it is is only meaningful to technical people; saying what it does doesn't add to anyone's understanding. I started this section in order to list some implications between the two, so to add meaning to what it is and overview to what it does.
* The comparison is there for contrast; it's not about which protocol is best. Often, as in this case, it's more telling to describe what it isn't, especially to explain the flaws it doesn't have. I think the ± notation makes it look more like a neutrality debate than it is – it isn't.
* There are some unresolved possibly implementational flaws that at least needs to be clearly separated. They do not currently aid the discussion of the inherent properties of the protocol, and they may be irrelevant if this is the goal.
—Anordal (talk) 00:23, 9 May 2023 (UTC)
thread_title:  Section «Comparison with USB Mass Storage» has issues