porg
commented
2 years ago As I learned and positively tested meanwhile:
- You can also sync from
iTunesFSto aFAT16 Volumewith its very limited filesystem metadata in the convenient GUI app Carbon Copy Cloner when using the option FUSEOptionAllowOther.
rsync --recursive --verbose --itemize-changes --modify-window=2 --exclude "PlaylistsTrackFormat.txt" --delete /Volumes/iTunesFS/Playlists/By-Device/mp3-player/ /Volumes/MP3-PLAYER-VOLUME/My-Playlist/
Explanations
I do not use rsync's commonplace
-a--archiveflag, because the whole Unix stuff which is included in--archive(owner, group, permissions) will always differ if the destination is a FAT formatted drive, which is the case for most mp3 players.--exclude "PlaylistsTrackFormat.txt"because we don't needs them at the destination. Some very dumb and chunky players may even choke on a text file and abort playback. More clever ones will skip it. But by excluding it in the sync we avoid that problem beforehand.--modify-window=2because--modify-window=0is too strict, because due to FAT's lower time resolution for the timestamps will often differ even though it it's the same unchanged file.Alternatively you can simply use
--ignore-existinginstead of--modify-window. Then any file which is already at the destination with this name is assumed as being same as on the source and skipped. Should you have updated an MP3's cover art or ID3 tags these changes would be undetected. But to simply compare by filename is the most rudimentary comparison, which may be handy for some use cases.Beware that in your iTunesFS file naming scheme you use
%(playlistNumber)then if you change the track order in a playlist, the filename changes and is considered as new, even though it is the same. If you just delete a single track from such a playlist all tracks thereafter have their playlistNumber shifted and would re-copy on the next sync!Closing Words
@users: I hope this hints may be handy for you.
@znek : Feel free to integrate this to Readme.me or the projects's website's FAQ.