(Update: see also my posts about the video problems and about the new firmware with Ogg Vorbis support.)I've recently purchased a SanDisk Sansa Fuze MP3 player. My old player has served me well for a very long time, but it's age is showing and I thought it was finally time to retire it. These are my notes on getting the Sansa Fuze working with my Acer laptop and Ubuntu Linux.
I selected SanDisk player after googling revealed encouraging reports about it's Linux compatibility and, especially, after I discovered that SanDisk explicitly mentions Linux in it's product specs. It also had some very nice features when compared to some of it's competitors, FM radio and voice recording for example. Also, I had seen some rumours about upcoming
Ogg Vorbis support. Now, rumours are rumours and I believe when I see it, but ogg support would be absolutely fantastic.
ConnectingMP3 players in general use two different protocols to communicate with the computer. The older MSC protocol tends to work well with different operating system as the device shows up as a mass storage drive for the computer. Microsoft's newer MTP protocol, designed to implement DRM restrictions to players, usually requires special software. Then, of course, there are some variations of the two. For example, Microsoft apparently uses protocol called MTPZ for Zunes for some reason. Go figure.
Anyway, Sansa Fuze claims to support both of the aforementioned protocols, but only MSC for OSX and Linux. So I wanted to try that protocol first. I connected my player to my Acer 2970Z's USB port and waited. Nothing happened on the computer. The Sansa Fuze claimed it was "connected", but lsusb didn't show anything new. Oh well, I expected this much. So I tried
this tip for another SanDisk player (removing kernel USB 2.0 driver with "sudo rmmod ehci-hcd", see also
this post) and sure enough the player mounted immediately. At least now I knew my player could be mounted, even if at suboptimal speed. Fortunately I found out that the speed could be improved easily by reloading the kernel module after Fuze has been mounted ("sudo modprobe ehci-hcd"). This remounts the player and copying is much faster. Later I also discovered that if I use a passive USB hub the player seems to mount with no mod-magic from time to time, although not consistently.
Here's the command I use to get the player recognised. The sleep command gives the player some time to mount and increases the chances of this working slightly, I find:
sudo rmmod ehci-hcd; sleep 1s; sudo modprobe ehci-hcd
(Update: apparently, it at least sometimes suffices to use "lsusb".)
I copied a few mp3's and an ogg file to the root folder of the player. Mp3's worked, the ogg didn't (as expected, of course). I then copied much of my music library to the device. After doing this I discovered that m3u playlists showed up on the player, but they didn't work. More about this below.
MTPUnfortunately, MSC mode does not show the content that had been preloaded to the player. So next, I tested
the MTP support with MTPFS, which is supposed to enable drag'n'drop copy to MTP players from Linux. Apparently, it also has playlist support. So I disconnected the player, typed sudo apt-get install mtpfs, and set the player to MTP mode. I also reloaded the USB 2 kernel module just to see if it matters. Then I reconnected player. Nothing happened.
Mtpfs actually uses libmtp to connect to the player, so next I installed libmtp's mtp-tools with "sudo apt-get install mtp-tools" and ran mtp-detect, which promptly informed me that "No Devices have been found".
I proceeded to install
the latest libmtp and mtp-tools from source (version 0.3.0). I found
a helpful post at the Sandisk forums and followed it as far as it was applicable. The installation required some tweaking, as it apparently installed some files to non-standard locations and this left me for example with two versions of tool executables. Now I finally got mtp-detect to see my device. Amarok, Rhythmbox or mtpfs didn't see it, though. But I was still able to download the preloaded content from the player with mtp-tools.
Here is the one-liner I used to generate a command line for getting all the MTP mode tracks from the player:
(mtp-tracks | egrep -w '(Track ID|Origfilename)' |sed 's/[ \t]*$//'| sed 's/^.*D: /\" ; mtp-getfile /' | sed 's/^.*e: / \"/' | tr -d '\012' | colrm 1 4; echo \")
Not very elegant, very much ad hoc, but worked for me. As the command actually just prints a download command, which you can then check before pasting and running it, there should be no risk trying it. But, of course, I promise nothing and give no guarantees.
At this point I gave up on MTP for the moment and turned the player back to MSC mode. (Information from mtp-detect should probably be posted at
libmtp bug tracker. I haven't got around doing this yet, unfortunately, as MTP isn't a must for this device. Perhaps someone else will find the time.)
VideoGetting video playback is a whole different story. Others
have tried with no real success (see e.g. reqeya's post). First I copied the video file preloaded to the player and transferred it back with a new name. It worked. Then I tried copying some random avi files to the player. The player detected these files as video, but complained that they were in a wrong format. No surprise there.
Next I downloaded Windows software Sansa Media Converter from Sansa web site and tried it under Wine and in a virtual machine. Neither worked.
I tried numerous different things to get video working. Again and again, the player said that the media format is unsupported. I'm not very optimistic at the moment, as further investigation revealed that the player requires very specific format for the avi container. See
the post I wrote about this for further details on the problem and the format used by the player.
I don't know much about video encoding and would appreciate if anyone else could give some advice on getting video work. For reference you might want to see
further information on the video clip and
this discussion. It's also worth noting that in the past others have had
some success with earlier Sansa models and video, but the player's video format has been
ridiculously specific. And they have of course changed the format for this model.
Let me know if you find anything useful.
PlaylistsI already mentioned that m3u playlists seemed to be supported in principle. Some additional work is required, however, to get them fully functional. I tried creating a simple m3u file in the root folder of the device with only two entries. I created two versions of the file: normal one with a text editor and a dos version with unix2dos. Both showed up on the device but neither worked.
After some additional frustration I installed Easytag from Synaptic. This is how I got my first working playlist with a single song. I then copied this playlist to a different name, opened it in nano, changed the single entry in the file into a different file and saved. This also worked. Then I created my own list with identical input with nano and ran the file through unix2dos. After several tries I got this working too. As far as I know it is essential that the playlist has CR's in the end of every line:
$ cat -A list.m3u
#EXTM3U^M$
#EXTINF:259,song1.mp3^M$
song1.mp3^M$
The playlist must also use relative paths and Windows-style backslashes as directory separators.
Quite bizarrely, some of the stuff I tried seemed to work on and off. It seems that there were some random errors, possibly due to me yanking the usb cable on and off constantly. So, to be safe, you probably should wait for a while before detaching the cable, or you should unmount the device cleanly.
I have written some custom scripts that generate a few playlists automatically from my music collection. Unfortunately I noticed that Fuze read these very slowly and worked with them only after pushing menu button and back after the list had been loaded. Strange.
SlooowThe most notable annoyance with the player has been it's slow functioning. Apparently several gigabytes of music on a VFAT drive is just too much for it.
Especially slow is the "database update" after file transfer. This is mostly due to the numerous media files on the player, but still it could be a bit snappier. This also makes testing playlists etc. painful. Fortunately files in RECORD directory, for example, are not indexed, so you can put there everything that doesn't need to be indexed.
Playlists are also read very slowly. If a playlist is long, reading it will take forever. The best way to cope with these problems, I think, is to use only small playlists. Better way to categorise files is to set their genres to your liking with Rhytmbox/Easytag. Genres are indexed during database update and can be accessed almost instantly.
One other observation, that I can't be sure about at this point, is that the player seems a bit faster when mp3's are scattered in different directories in root folder, rather than all in MUSIC-folder. It also seems that very long file names may cause some sporadic file system problems from time to time. So, I have decided to remap my music collection to the root folder of the player, in a few directories with short names, with no folders for albums and such. I have automated this with a script that rsyncs my music collection to the device.
I've also had
this problem with file transfers from time to time, where nothing is copied to the player and the system says the file system is read only. I'm not sure but
perhaps this has something to do with filenames starting with a dot. After that remounting and deleting the file sometimes helps:
sudo mount -o remount,rw /media/SANSA\ FUZE/
A Few Further NotesMy firmware version was V01.01.11F, which at the time of writing this is the newest. So there was no need for firmware update. Apparently you can update firmware, however, without Windows just by dragging firmware .bin file to the device root in MSC mode. I haven't tested this.
I have some mp3 files with broken unicode characters in them. During this exercise I found that it is just easier to remove them from filenames than to get them working with Fuze and playlists. Here's one pretty demented way of doing just that:
ls --color=none -b1i | while read i; do find . -inum ${i%% *} -exec mv {} ${i#* }" \;; done
That took some experiment to get working. If you have just one or two broken filenames, it is easier just to rename them in Nautilus. Unfortunately, I had tens of them. This command is probably not the ideal way to rename files, but again, it was good enough for me.
Some discussion on Sandisk forums:
ConclusionsAt this point it is hard for me to say whether I would recommend this player for Linux owners. SanDisks attitude towards Linux seems somewhat positive and they deserve to be rewarded for that. On the other hand, their media conversion software is still Windows only and their video format is just silly. The player probably takes some time to get used to, but at this point it does seem slow. Also, managing a large number of media files is not very easy.
This page chronicles the several problems I have had with this player, many of them in no way related to Linux. In general, I'm not happy with the quality of its software, especially. But from my own experience and from what I gather from the forums, other players are not much better. My suggestion is to research your own purchases thoroughly beforehand.
