how to get the sansa connect to connect to ubuntu

it is really a bunch of ■■■■ that sandisk made a player that does net connect to linux in fact this is the last thing i will ever buy from them even if they start making them to work with linux anyway lets start getting this piece of ■■■■ to work with linux…

1.) run the recovery tool so you get the default firmware

2.) put it in flight mode so you don’t get newer firmware (another really crappy thing sansa did is block what i am getting ready to tell you to install.)

3.) now install gnomad2, libmtp, libnjb now with a empty mp3 player reboot both the mp3 and linux then plug in the mp3 player and with gnomad2 you should be able to drag song’s on it.

all done

sansa don’t ever make ■■■■ like this again it will hurt your buiness in the long run i know i’ll tell all my friends not to buy any sansa products i won’t buy them after this

No offense, but why did you buy a Connect if you knew it was only Windows compatable, then complain when it doesn’t operate(right out of the box) with anything but Windows?  The specs are clearly given as far as operating systems and compatability, so I’d say your aggression is misdirected.

It is cool that you were able to get it worked out though.

the sansa connect is an MTP only device.  you have to install additional MTP drivers for the OS to make it recognize the player.  try to search “ubuntu MTP drivers” on google

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

I have read in the libmtp mailing list that with the latest firmware the Clip+ works ok with it. I don’t know if developers read my post or what, but in any case, great job and thanks for fixing it :smiley:

The funny think is that the Sansa Connect firmware is based on Linux!  See this.  If only we had the freedom to fix it (firmware updates must be signed by a private key that we don’t have).

I’m not much of a fan of MTP for the reasons stated.