Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I was going to copy my (mp3-encoded) music files (organized in one directory) to a (vfat-formatted) (micro-)sd-card to use it in my digital audio player (DAP) (on Linux). I used to use the same combination for about 1 year now and it always worked.

Now I ripped a huge part of my CD collection, so the number of files increased dramatically and I updated the tags for the old files, too. So basically I had to copy most if not all files to the card anyhow. That is why I decided to start with a fresh formatted SD-card:

sudo mkfs.vfat /dev/mmcblk0p1

Then I just copied my music to the card:

mount /mnt/cardreader
cp -r ~/music/* /mnt/cardreader/
umount /mnt/cardreader

where my /etc/fstab contains the following line

/dev/mmcblk0p1          /mnt/cardreader auto            noauto,user             0 0

After updating the DAP's database and playing some music (using RockBox), I noticed short portions (maybe 1-2 seconds) of other tracks "mixed" into the songs that were stored on the SD-card. This did not happen when I played a song stored on the DAP's internal storage.

So I plugged the SD-card back into my Linux-box, mounted it and played some songs using mplayer. This gave the same odd behavior. Even playing just one song, others were mixed in, so I ruled out any RockBox-database relation.

Running fsck.vfat returned a lot of errors (which I did neither remember in detail nor recorded, unfortunately). So I decided to start over again and use rsync this time since, according to its man-page

...rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred...

and I want future updates to copy only new/changed files anyhow:

mount /mnt/cardreader
rsync -rltDvP --modify-window=1 --stats ~/music/* /mnt/cardreader
umount /mnt/cardreader

This runs several hours and sometimes fails complaining about the target filesystem being read-only or failed attempts to change permissions. This is somewhat irritating since the SD-card was mounted read/write and there should be no approaches to changes permissions (no -g or -o option given to rsync) but running rsync several times eventually let it finish without errors. If it kept on complaining about the SD-card being read-only, remounting it fixed that.

However I keep encountering the described problem and

sudo fsck.vfat -aV /dev/mmcblk0p1

complains about bad short file names and tries to rename the same files over and over again without finishing (I waited about twice as long as it took to copy the files using cp).

  • What would you recommend to track down the error?
  • Is there a better (i.e. more secure) (Linux) way to copy those files to the SD-card?
  • Do I use the wrong options for one or more of the above calls?
  • Or do you think my SD-card (which worked like a charm for the last year) just happened to break when I decided to update my music library?

Addendum

Even though I noticed the problem using my DAP, it also happens when I format, mount, rsync, umount, unplug the card, reboot the computer, plug in the card, mount, rsync (doing nothing) and play a file: Playing from the SD-card is "remixed", playing the source file sounds normal.

share|improve this question
    
I had exactly the same symptoms a long time ago using an mp3 USB stick. Maybe you started the umount process but did not wait until it ended? –  Tim Aug 16 '13 at 11:23
    
@Tim: I ran all the above commands from the same shell. I assume that umount would not exit before it was done, would it? How could I check if it was done? –  sg-lecram Aug 16 '13 at 14:59
    
It would not exit before it was done. Since umount is the last command, I was not sure if you waited until it returned (and you could execute the next command). What does happen if you do not put it into your DAP? Just transfer the files and plug the card out as usual. Then some time later (maybe even after a reboot) use rsync to check if your transfer was successful. If yes, try if your DAP screws it up... –  Tim Aug 16 '13 at 15:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.