Talk:Media Transfer Protocol

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.

Main Purpose of MTP?

The General section claims that: The main purpose of the protocol is to transfer media files. However, if that were the case, then surely UMS would simply have been adopted. Can we not therefore conclude that the main purpose of MTP is to enforce DRM? -- Ralphbk 08:35, 13 November 2007 (UTC)[reply]

No, this is not the main purpose behind the protocol. Moreover, the MTP Basic component of the protocol does not use DRM at all, and this is the component that is up for standardization. --Meiqur 07:45, 15 February 2007 (UTC)[reply]

While DRM support is a part of Microsoft's implementation, I believe the syncronization, automatic transcoding and syncronization are very compelling features. What worries me is that while you can turn off MTP and revert to a UMS mode on my Sansa player, nothing uploaded in MTP mode is even present in the UMS filesystem. But this just may be a fluke of my particular implementation. http://www.directionsonmicrosoft.com/sample/DOMIS/update/2004/10oct/1004mpumsf_sb.htm 68.226.79.69 17:37, 18 September 2007 (UTC)[reply]

I would argue that this is another monopolistic attempt on Microsoft's part due to the fact that the only OS that really has decent MTP support right now is Windows. Why else would they completly cut out support for MSC (aka UMS) mode with Plays For Sure II? Currently Sandisk is updating the firmware on some of their MP3 players so that they will no longer have a selectable MSC mode as part of the compliance with Microsoft.23:40, 12 November 2007 (UTC) —Preceding unsigned comment added by 168.184.247.53 (talk)

Yes, Main purpose is DRM, and I think someone should write about this in the wiki itself. I am no authority on DRM but but it seems to me that MTP will do nothing but make it difficult to copy my music from digital music player to hd etc.. It will also make carrying software, other than music, on these devices. Why? —The preceding unsigned comment was added by 71.108.4.144 (talk) 10:14, 19 March 2007 (UTC).[reply]

No, it is absolutely possible to make MTP devices with no DRM at all. The main points about MTP are listed on the page. Do not confuse MTP with Janus, these are two separate things, even though they often appear together. Nixdorf 20:17, 19 March 2007 (UTC)[reply]

OK, so it is possible — but did any manufacturer actually do it? If so, how did they think that helped their end users? Because I am sitting here with a MTP:ed iriver T30, and I cannot see how this is better than USB mass storage. I (my kid brother, really) expected this player to act like a normal USB memory, i.e. be usable with any modern computer, with no unreasonable OS requirements and no weird software to install first. JöG 21:23, 11 April 2007 (UTC)[reply]

@JöG: You and your kid brother might find the iriver firmware updater useful. Ralphbk 06:48, 12 April 2007 (UTC)[reply]

The Samsung SGH L760v does not support DRM portions of MTP. Nixdorf (talk) 14:07, 6 May 2008 (UTC)[reply]

Exactly how I felt when first hooking up my Samsung YP-K3. I don't use WMP, wasn't interested in WMP10, but eventually was forced to install it. Copying files to it is kind of hit and miss, slow, and difficult to determine how much data in actually on the thing.

He's right, a very large percentage of XP computers do not have support for MTP mode due to MS stupidly bundling it with WMP10 which a lot of people don't bother to install. Additionally many times MTP drivers can have issues even with WMP10 installed. 23:42, 12 November 2007 (UTC)

The point of the protocol is to provide a standard means of transferring media and metadata between a computer and a device. The advantage is that it is generally much faster than MSC when transfering media files, as the device doesn't need to scan through each file to update it's database (in my experience, there's about a 20% speed increase on a Sansa E200 for synchronizing a couple hundred songs including database update, though raw data transfer speed is slower for MTP). A properly tuned implementation which didn't need to support MSC as well would probably be just as fast as MSC for data transfer, if not even faster. Whether it can be used for DRM or not is irrelevant, and the monopoly argument is severely flawed now that it's an official USB standard (the 'enhanced' operations stuff is still pretty dubious though). As for cutting support for MSC in PlaysForSure, MTP would be easier to extend for DRM, and Microsoft probably wants to encourage people to use MTP anyway since they went through all the trouble of writing it. In any case, claiming that the purpose of MTP is to enforce DRM would be original research and highly dubious. -- Fanta2 (talk) 13:42, 8 November 2009 (UTC)[reply]

MTPSync

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)[reply]

Possible plagiarism

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)[reply]

Philips GoGear

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)[reply]

Erroneous statement ?

"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)[reply]

Fixup

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)[reply]

MTP and KDE

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)[reply]

MTP problems in windows

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)[reply]

Windows "Data security flaw"

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)[reply]

"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)[reply]

An administrator could just as easily install a program which allowed him to remotely view your screen, or log all the data you sent over every single USB interface of every kind. Nothing is ever secure from an administrator account. If you don't trust the administrators of a computer, you shouldn't be doing private things on it. There's nothing MTP-specific about that. – Smyth\^talk 13:36, 21 April 2013 (UTC)[reply]

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)

"Control" vs "allow"

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)[reply]

MTP is not built on top of USB Mass Storage, so it doesn't make sense to talk about "underlying abilities" of USB which are "already there". It is simply a different way of accessing an external filesystem, at the level of files rather than disk blocks. This allows certain activities which would be impossible under USB Mass Storage, such as simultaneous access by the device and the host (to different files, of course).

He is obviously trying to make a point about DRM, but the article makes it clear that DRM is an optional aspect of MTP which is not even part of the core protocol. For example, it is not used in the Android MTP implementation. – Smyth\^talk 14:54, 20 April 2013 (UTC)[reply]

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)[reply]

The "underlying interface" is simply a raw USB, TCP or Bluetooth connection, i.e. a 2-way byte stream. It has no "functions" in itself, so there is nothing to be "gated off". So I really don't know what your point is. Would you also replace "allow" with "control" in an article such as SMTP? – Smyth\^talk 13:47, 21 April 2013 (UTC)[reply]

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)[reply]

Again, nothing is being "blocked", "replaced", or "interrupted", because the underlying protocol layers do not do anything other than provide a communications medium. A USB interface is not capable of accessing a disk by itself. You are making an implicit comparison with USB mass storage, but as I have already shown, the features of MTP are not a subset of the features of USB mass storage. 00:31, 28 April 2013 (UTC)