[Ifp-driver-common] Re: formatting a UMS iRiver for use on linux

[Michael S. <ms...@cl...>]

> The best way I found to have an acceptable MBR on the iRiver player,
> without those silly four primary partitions which windows creates, out
> of which only one is usable (/dev/sda4 on linux), is to simply do a
> 'fdisk /dev/sda', supposing that's where you have your iriver --it might
> be /dev/sd{b,c,d,e,...} depending on whether you have other scsi devices
> on the system (yeah, the iriver is not scsi but usb, what happens is
> that usb-storage, which the iriver uses, is implemented over the scsi
> layer-- ... err, sorry for the length of the message.
> 
> >From the fdisk prompt just remove all the partitions, leaving the iriver
> completely unpartitioned, save the changes and instead of creating the
> filesystem wih mkfs.vfat or using windows, simply unplug the unit from
> the usb port and turn it on. Supposing you already had the UMS firmware
> installed, a message will show up on the screen explaining that the unit
> is being formatted.

Well, I did this but for some reason all my mp3's are still on my mp3 player.
The strange thing is that the sda1-4 are gone and only sda remains.  It still
reads 110M.  

Thanks for all the help thus far man!!!!



On Fri, 2004-02-13 at 21:46, Javier Marcet wrote:
> * Trey Gruel <dra...@ni...> [040213 16:46]:
> 
> Hi iriver mates :) I'm reading the list again.
> It sure is a nice coincidence but we all (the onews writing this thread,
> anyway) seem to use Gentoo :))
> 
> The patch I had done is included in love-sources
> http://www.linuxmall.us/~lovepatch/love-sources/
> Although I have problems with all the 2.6.2+ versions, hence, I use
> gentoo-dev-sources over which I apply a tad amount of patches I have
> over here.
> 
> If you still need the patch, you can still get it from the address I had
> initially posted ->
> http://perso.wanadoo.es/smarcet/015_iriver_NORMB.patch
> 
> >> This forced me to do a format (which I did on my friend's window box). 
> >> When I did this, windows would only format 109M when my player is a 128M
> >> player.  Before it was formated for 128M.  
> 
> >> Anyone have any suggestions on this one?
> 
> >That's windows setting aside some space for the "Recycle Bin".  To get 
> >that space back you need to tell windows to let you not use the recycle 
> >bin for that drive.
> 
> >(Using XP as a guide as it's the only windows I have accessable ATM)
> 
> [...]
> 
> >I think other versions of windows do it the same way, but I'm not 100% 
> >sure.
> 
> >As a side note, does anyone know whether or not mkdosfs or mkfs.vfat in
> >Linux will work for formatting an iFP for UMS use?
> 
> I'm pretty sure I had already written about that on this same list
> around the same time I posted the patch.
> 
> The best way I found to have an acceptable MBR on the iRiver player,
> without those silly four primary partitions which windows creates, out
> of which only one is usable (/dev/sda4 on linux), is to simply do a
> 'fdisk /dev/sda', supposing that's where you have your iriver --it might
> be /dev/sd{b,c,d,e,...} depending on whether you have other scsi devices
> on the system (yeah, the iriver is not scsi but usb, what happens is
> that usb-storage, which the iriver uses, is implemented over the scsi
> layer-- ... err, sorry for the length of the message.
> 
> >From the fdisk prompt just remove all the partitions, leaving the iriver
> completely unpartitioned, save the changes and instead of creating the
> filesystem wih mkfs.vfat or using windows, simply unplug the unit from
> the usb port and turn it on. Supposing you already had the UMS firmware
> installed, a message will show up on the screen explaining that the unit
> is being formatted.
> 
> After all, if it formats itself, it sure knows how to do it better than
> any OS. If you plug in it to the USB after the format is over, you'll
> have to make the two dirs the unit needs on its root folder, called
> 'RECORD' --where it'll save radio and line-in recordings--, and 'VOICE'
> --where it'll place voice (mic) recordings--.
> 
> Beyond those two you can create whatever you want, with the only limit
> of keeping below 1024 the number of folders on the root dir --I haven't
> tried that, it's said in the manual which came with my unit--.
> 
> By the way, after being formatted by itself, I access it from /dev/sda,
> as if there were no partitions.
> 
> Also, as pointed out by some of you in another message, the iriver does
> not show the files in alphabetical order, but in the order we copy the
> files. That means that if the first folder you create is 'VOICE',
> that'll show up first, if you then create 'Albums' or whatever you want
> to make, that'll come in second, if you then create the other needed
> folder 'RECORD' that'll show up as the third folder on the root. So not
> even the mandatory folders need to be the first ones.
> 
> Knowing these you can order the folders and files the way you want by
> just moving the folders and files around. The copying from the PC to the
> irivr is slow, but once the files are on the usb unit, you can move then
> freely in real time.
> 
> Another ebenefit of the UMS firmware I found is that you can edit the
> ID3 tags after you copied the files as you can copy them back to the PC,
> be it yours or any other to which you might plug the unit, unlike the managed
> firmware which does not let you copy back mp3s files to the computer
> once they are on the unit.
> 
> All in all, I see no reason to not use the UMS firm.
> 
> Just in case you are interested, this is the line I put on my /etc/fstab
> to mount my iriver player:
> 
> /dev/sda    /mnt/ifpdev     vfat    noauto,sync,noatime,user,nonumtail,shortname=mixed,codepage=850,iocharset=iso8859-15    0 0
> 
> /dev/sda is the iriver device
> /mnt/ifpdev the folder where it is mounted on
> noauto means the unit is not mounted automatically at boot time, after
> all it is not plugged all the time
> sync is to not delay the write operations, but do them at the moment the
> are requested, so that there's no delay to umount the unit or anything
> else
> the othere parameters affect the treatment of large filenames (beyond
> 8+3); you can read more on the mount(8) man page.
> 
> 
> If you have any other problem simply say so, and please send a copy of
> the message to my e-mail address, just in case I forget checking the
> list again :)
>