Reading the online pdf file that is the owners manual, I read a warning that removing the device or breaking the connection whlie the device is connected via the usb port to the pc and actively transferring data is enough to permanently break the Fuze.
Doesnt this sound like the kind of thing which would Mandate an immediate firmware update? Its so easy for folks on a hurry, or not having read and retained everything in the owners manual to simply disconnect the usb cable, or, upon thinking they are done , doing the same… For their to be no protection, ie, no buffer of data, or no other protection, this sounds like a really bad oversight, and not at all indicative of a quality product, or company which operates within a quality framework.
Is this kind of thing acceptable to most of you guys? I dont know how iPod does it, but Id bet almost anything that they have designed something to prevent a device seize up or total failure under such conditions.
And, there is nothing in the quick start guide which comes with the device that even hints of this problem. You have to log onto to the sandisk website and load up the pdf file in order to even read that. So considering that removing the device before the transfer is complete can make the device inoperable, at the very least, there should be a warning very clearly displayed with every new unit that this is the case.
I think that’s more of a CYA disclamer. It’s actually pretty hard to permanently brick a Sansa. There are a number of recovery options that can get you out of almost any software/file sytem corruption situation. And if none of those work it almost guarantees there is an actual hardware problem. I don’t think Sansas are more susceptible to interrupted transfer problems than any other player.
The iPod screen changes to “do not disconnect” when you have it connected to the PC. If you do disconnect it, it can get pretty messed up too. iTunes expects you to disconnect via software. The Fuze doesn’t insist on using a specific piece of software, so it can’t really work this way.
It seems like it would have been a good idea for the Fuze to say something about not disconnecting when data is being transferred.
Note that the new generation of Sansas have a new processor family, with no needed Recovery Mode or bootloader fragility seen in the earlier devices.
These wee beasties are pretty resilient when it comes to file transfer and recovery from corrupt data.
As long as the device can establish communication with the host computer, feeding the device a new firmware copy starts them right up on the first attempt. The system is configured for a hardware-selectable MSC connection.
On the occasional freeze, a soft reset does the trick. Beyond that, SanDisk has been quite responsive in replacing defective devices.
Bob :smileyvery-happy:
Message Edited by neutron_bob on 06-19-2008 01:11 PM
So bob, what Im getting from all this is that, even though my device may have been separated before it had closed out the transfer due to that ‘remove 90mb data’ msg during or near the end of the transfer, which is kind of weird since 400 songs in my mp library should only take about 20% of the available 8gb space, its not guaranteed that this will cause a permanent crash condition such as I had… Does the Fuze have this new Processor Family you refer to, that is more robust? Should I have to immediately download a new firmware version, or, should it be working properly with the firmware it has as a new Fuze device?
If the filesystem becomes corrupted you can get that message. So in that case a device format will restore the player. Connect to the Computer in MSC mode.
sansafix… there still is some confusion about which mode to use. .I have all my albums ripped in Media Player 11 and I plan to drag them all into my Synch window and to manually select ‘start sync’ to begin the process when my replacement player arrives. For this type of use, I gather either mode would be ok, although Ive read that database refresh is quicker with MTP, but transfer itself is quicker via MSC because database refresh does not occur after every song or album like I read it does with MTP…
If I plan on doing all my refreshes this way via a manually created sync list in WiMP 11, is there a defined mode to use?
MTP transfer is actually preferable, since the data transfers are not cached in the same way as MSC (requiring the “safely remove hardware” function). The Fuze functions very well with MTP mode and Windows Media Player 11, including the album art.
The “slower” transfer many refer to is only involved with WMDRM issues and copy protection, as the music file is intertwined with a leaf license. MP3 files, or wma without copy protection, fly on the USB2.0 bus.
Many do not like WiMP11 as problems with the MTP drivers are very common. Computer-specific driver issues have been a headache for many, and the solution often has beeen to leave the MTP arena for drag and drop simplicity, in MSC mode.
If MTP mode is working correctly, you’re in business! The real headache is getting used to the WiMP11 interface, and synchronization tricks. Microsoft has got to have the worst situation in that nobody there seems to have the time to sit with an average user and watch how hard it is to figure out the workings of the media player. The online help is cryptic at best. It device setup doesn’t go just right, WiMP has a habit of going hog wild.
The Sansa is happy regardless of the synchronization software you choose. WiMP is great in that I can wipe the memory clear for any reason, test or experiment, and pop everything back on in moments. Playlists are a snap too, and podcasts are easily updated.
MTP mode is required for any WMDRM or “Plays For Sure” encrypted media. Man, did the marketing wizards blow it on that logo! In my opinion, when a programmer was asked, “Well, did you get that thing to quit hanging?” the reply was, “sure, it plays.” Somebody in a nearby office cubicle had a Maalox moment on that one.
Thanks Bob… Sounds like Sansa could have done themselves a big favor and made themselves real heroes with the ‘avg user’ by not leaving out the owners manual from the box, trusting every user will log onto the sansa site and dl the pdf manual file, and also, by giving much more complete instructions for transferring music from several different sources whether it be media player 11 or whatever. Even if its Microsofts fault for cryptic WiMP instructions, Sansa is the one that will suffer… after all, if you cant figure out how to load your new Fuze the way you want, its not Microsoft youre swearing at!
I cant thank you enough for addressing my questions. I think Im ready to try it again when the replacement arrives, and not worry so much that if I look crooked at it, it will die on me again!
The new Fuze is packaged with the “1.0” mini CD, a Rhapsody 4 disk (actually, that’s what my particular one had hiding inside). Since I already am running the R4 client…the disk is in the box.
Starting that CD (the Autorun file), there’s a mask for installing Rhapsody only. I would have installed a copy of the Media Converter and an Adobe pdf file copy of the User Guide, but that obviously wasn’t my call.
In the User Guide, the graphic tutorial for working with WiMP is actually far better than anything I’ve seen on the Microsoft side.
MTP transfer is actually preferable, since the data transfers are not cached in the same way as MSC (requiring the “safely remove hardware” function).
There may be other reasons to prefer MTP (not for me, however ) but this is not one of them. In Windows you have the choice of “Optimize for performace” or “Optimize for quick removal” for MSC devices. If you use “Optimize for quick removal”, there is no write caching and you can remove the device without using Safely Remove Hardware. I believe “Optimize for quick removal” is the default in XP.
It said that when doing a firmware update, you need to attach the unit to the pc in MSC mode… So, lets way we want to normally use MTP, but are doing a firmware update… Do we attach the player after setting MSC mode, do the firmware update, remove the player, set it to MTP mode, and then reconnect?
I see there is a third mode setting under USB: ‘AUTOMATIC’… any reason to or not to use that one?
you can do the firmware update in MTp mode as well no reason to switch to MCS. Auto detect mode will switch to MCS if the MTP drivers are not present on the host machine.
That’s right, the device can be in either mode to accept the firmware. The only difference is that if you are in MTP mode, clicking on the device will yield “Internal Memory” first. Just double click on that to open the root directory.
It is possible to permanently damage flash memory if it is disconnected in the middle of a data transfer. By permanently, I mean reformatting will not fix it.
There is a key difference in the USB modes. In MSC mode the computer takes over control of the flash drive. In MTP mode the device controls its own flash drive and acts as an interface with the computer.
MSC:
computer <-> flash drive
MTP:
computer <-> player <-> flash drive
Thus, in MTP mode, the computer does not have direct access to the flash drive (internal memory). Windows will do a pretty good job of masking this on some players, making it appear that you have access to the flash drive for dragging & dropping, deleting, etc., but in actuality everything has to go through the player.
Here is where the difference in the USB modes can come in. If you disconnect the player during the middle of a transfer while in MTP mode you are not going to damage the player’s internal memory. (Don’t trust me on this enough to try it at home, of course.)
On the subject of Autodetection, my experience has been that Auto = try to connect in MTP mode, and if that fails, keep trying to connect in MTP mode no matter what until the user contacts tech support and the tech support representative advises to switch to MSC mode. It would be nice if Auto mode could detect when the MTP drivers failed to install, and then attempt to reconnect in MSC mode in that event, but from the player’s standpoint, the player probably has successfully connected (hardwarely speaking) to the computer in MTP mode and has no way of knowing that Windows is having MTP driver issues.
“…On the subject of Autodetection, my experience has been that Auto = try to connect in MTP mode, and if that fails, keep trying to connect in MTP mode no matter what…”
Hmmm… I would think thats exactly how MTP mode Should work, not Autodetect. Autodetect should try first to connect in MTP mode, and upon failure one or perhaps twice, then try to connect in MSC mode.
To keep trying to reconnect ad infinitum in MTP mode would be the way we would expect a device configured to MTP mode to work, and the same thing if set to MSC mode. What youve described is not really autodetect at all but rather some type of persistant trial-connect in whatever mode is being used with no mode switching at all. Its kind of misleading if thats the way it really works.
That makes absolute clarity of it! I connect to two earlier systems, a Windows ME and a Win2000 machine, and the Sansas don’t hesitate, they go directly to MSC for rapid file transfer.
In my case, being able to zip files to these earlier machines in MSC, separated from the (more important of course) MTP data (the stuff for my ears), is quite automatic, thanks to Auto Detect.
) but this is not one of them. In Windows you have the choice of “Optimize for performace” or “Optimize for quick removal” for MSC devices. If you use “Optimize for quick removal”, there is no write caching and you can remove the device without using Safely Remove Hardware. I believe “Optimize for quick removal” is the default in XP.