You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I do not use rsync's commonplace -a--archive flag, 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=2 because --modify-window=0 is 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-existing instead 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.
The text was updated successfully, but these errors were encountered:
You can also sync from iTunesFS to a FAT16 Volume with 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
--archive
flag, 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=2
because--modify-window=0
is 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-existing
instead 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.
The text was updated successfully, but these errors were encountered: