I will answer that question: because Sansas are MTP compatible. And MTP is a standard protocol standarized by the USB Implementers Forum on year 2007. And the majority of MTP devices are implementing the MTP protocol in a buggy way because of the buggy Windows USB driver stack and the buggy controllers they use because they only test them on Windows. But at least they could adhere to the MTP standard which has nothing to do with the USB Windows driver stack and do corrections with firmware upgrades. That could be a good move and Linux users would put SanDisk in a very good place, I mean, good free marketing by a community which is very active on the Internet: I bought a Sansa Clip+ because people told me it supported OGG and FLAC formats (free formats) along with MTP.
SanDisk should test their devices against a libmtp program to see if it works out of the box.
You can get a picture of the workarounds needed for getting their players to work by reading this text on libmtp sources (device-flags.h) downloadable from here.
/**
* This flag indicates that the device will lock up if you
* try to get status of endpoints and/or release the interface
* when closing the device. This fixes problems with SanDisk
* Sansa devices especially. It may be a side-effect of a
* Windows behaviour of never releasing interfaces.
*/
#define DEVICE_FLAG_NO_RELEASE_INTERFACE 0x00000040
/**
* Some devices, particularly SanDisk Sansas, need to always
* have their “OS Descriptor” probed in order to work correctly.
* This flag provides that extra massage.
*/
#define DEVICE_FLAG_ALWAYS_PROBE_DESCRIPTOR 0x00000800
/**
* The Sansa E250 is know to have this problem which is actually
* that the device claims that property PTP_OPC_DateModified
* is read/write but will still fail to update it. It can only
* be set properly the first time a file is sent.
*/
#define DEVICE_FLAG_CANNOT_HANDLE_DATEMODIFIED 0x00004000
**
* This means that the PTP_OC_MTP_GetObjPropList is broken
* in the sense that it won’t return properly formatted metadata
* for ALL files on the device when you request an object
* property list for object 0xFFFFFFFF with parameter 3 likewise
* set to 0xFFFFFFFF. Compare to
* DEVICE_FLAG_BROKEN_MTPGETOBJECTPROPLIST which only signify
* that it’s broken when getting metadata for a SINGLE object.
* A typical way the implementation may be broken is that it
* may not return a proper count of the objects, and sometimes
* (like on the ZENs) objects are simply missing from the list
* if you use this. Sometimes it has been used incorrectly to
* mask bugs in the code (like handling transactions of data
* with size given to -1 (0xFFFFFFFFU), in that case please
* help us remove it now the code is fixed. Sometimes this is
* used because getting all the objects is just too slow and
* the USB transaction will time out if you use this command.
*/
#define DEVICE_FLAG_BROKEN_MTPGETOBJPROPLIST_ALL 0x00000001
These are the flags needed by libmtp for most of the Sansas. Well, having Sansa Connect as a Linux based device, I think it does not need much work for them to test players against libmtp as they have experience on working with linux devices.
So, SanDisk developers, if you are reading this, please, test devices against libmtp and fix your firmwares. It will work without problems (or better than before) on Windows and the 100% of customers will be happy. For example, my Sansa Clip+ connects to Linux and I can make transfers, but after some data collection from the device using mtp-tools the player locks up and I have to turn it off with the long press button and turn it on again. I’m using MSC mode because of this, when it should work in MTP because it’s a standard, an ISO standard.
Best regards.
Message Edited by Filiprino on 12-29-2009 06:52 PM
