Mounting the Rio MP3 Player as USB Storage Device?
 

I checked this on the HCL: http://www.linuxquestions.org/hcl/sh...=myprod&page=1

Apparently, that user had success in using his Rio as an USB Storage Device, and so was able to simply transfer files as though it were a normal hard drive.

I'm running SuSE 10.0 with the default 2.6.13-15 kernel. I have not been able to use the Rio as a USB storage device. In fact, no block exists at /dev/sdx, except for my hard drive at /dev/sda. Running lsusb, however, does show that the kernel does detect the USB device, but does not associate it with a node.

What do /var/log/messages or dmesg show when you plug the player in - do they recognise the drive being available and assign it a device entry?

tail -f /var/log/messages
dmesg This is after plugging and unplugging the device several times.
I don't compile my kernels anymore, but I used to under Slackware. I read somewhere that it might have to do with multi LUN, but my USB card reader works fine in SuSE out of box. I used to compile multi LUN support to get my USB card reader to work, so I don't think it's that.

ok but which rio?
 

perhaps I missed this detail, but I don't see which Rio player you are working with. There are many.

Some can be accessed as a mass storage device and some cannot.

A Rio Karma, for example, uses it's disk as a database--does not have a file system on it like a computer does. So a Rio Karma will not be able to be mounted as a usb mass storage device.

If you have a different Rio player, you need to see if it uses a fat filesystem (for example) that a computer can recognize, then it has a chance of being set up as a usb mass storage device.

My Vibes mp3 player uses the Rio Karma firmware as a code base, but they use a fat file system, so it is seen in Linux as a mountable USB mass storage device.

For comparison, here is the line I put in my fstab to mount a Vibez (rio firmware):

/dev/disk/by-id/usb-TrekStor_vibez_0510F7B07F6BA7D2C-0:0 /media/vibez vfat users,defaults,exec,umask=000 0 0

Note that the umask is the inverse of the permissions you want to give it. a umask=000 actually gives permissions of octal 777.

I should mention that I am using Linux SLAMD64 12.0 (a 64 bit distro based on Slackware ) and
I use the UDEV device names in the fstab so the device is mounted in the same place every time no matter what is plugged in on power up.

on multi-LUN support
 

Apachedude,
I forgot--you mentioned recompiling the kernel for multi-LUN support. I had to do that too.
The reason for doing that under any kernel, is to rescan the scsi bus for devices that have more than one LUN on the same device.
2 examples:
1. a Sansa E280 mp3 player has main memory as one LUN and the micro SD card in it as a different LUN but is seen as 1 scsi device. So you need to have multi-LUN support for a device like that, otherwise your computer stops looking for LUNs after it finds the first one on the device.

2. Not all 6-in-1 card readers are made the same. Some are made with type card as one LUN, and some are made with 2 or 3 different LUNs for different cards that can be inserted in the device. An example is the card reader built into my Dell 24" monitor--it uses 2 LUNS.

What happened to me when I did not have multi-LUN support compiled in was I would boot up with no card in the 6-in-1, then use a Compact flash card. When done, unmount it and take it out. Then if I inserted a memory stick into the 6-in-1, it would not find the memory stick at all. If I rebooted with no card in, then put a memory stick in, it would mount and read it. if after that I put a CF card in, and tried to mount it, it wouldn't read it. It would only use the first _type_ device inserted in the 6-in-1 reader after boot up.
To fix that problem, I did 2 steps:
1. recompile the kernel with multi-LUN support.
2. between inserting different cards, run a script that I had attached to an icon on my panel forcing a rescan of the LUNs. There may be better ways of doing this, and if so, I'm willing to learn.
Here is the simple script in case someone else reading this wants to do it:
---start---------
#!/bin/sh
cd /sys/bus/usb/drivers/usb-storage/
for x in `ls ?-* -d `
do
echo "found: "$x
echo -n $x > /sys/bus/usb/drivers/usb-storage/unbind
echo -n $x > /sys/bus/usb/drivers/usb-storage/bind
echo "">/dev/null
done
---end----------

Had I realized that all 6-in-1 card readers are not made the same, I might have just bought a different one and ignored the one in the side of the dell monitor (grin), but I didn't know that at the time I was trying to solve this. They don't say on the box what kind they are, so I still don't know how I would be able to tell what kind I was buying in a store...

Anyway, I just wanted to say some reasons to need multi-LUN support, and what the problem of not having that compiled in might look like.
I agree with you that that is probably not the problem with getting whatever rio you have mounted as a USB mass storage device.