Talk:Media Transfer Protocol

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)

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)

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)

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).

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)

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)

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

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

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)

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)

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)

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)

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)

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)

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