znek / itunesfs Goto Github PK

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.

This is more/less a duplicate of #1 but I tried to be as specific as possible with my observations, and also included an idea

Reproduction 1

• Change /Volumes/iTunesFS/AlbumsTrackFormat.txt
• Outcome: Finder windows having /Volumes/iTunesFS/Albums/* open refresh the file names according to your format change ca 2-3 secs after the config file was updated.

Reproduction 2

• Change /Volumes/iTunesFS/PlaylistsTrackFormat.txt
• Outcome:
  • Finder windows having /Volumes/iTunesFS/Playlists/* open refresh their file names according to your format change in the config file only some 1-3minutes later.

Observations

I guess the speed difference comes for the following reasons:

1. The "Albums" file/folder structure is strictly hierarchical, every item occurs only once.
2. Albums have only one central format definition at /Volumes/iTunesFS/AlbumsTrackFormat.txt
3. The "Playlists" file/folders structure is much more heterogenous, items can occur multiple times, smart playlists can produce massive result lists.
4. Playlists have a central definiton at /Volumes/iTunesFS/AlbumsTrackFormat.txt plus an override PlaylistsTrackFormat.txt at each playlist folder within /Volumes/iTunesFS/Playlists/*.

• a) As far as I can tell if you write to /Volumes/iTunesFS/AlbumsTrackFormat.txt this change is (virtually) written to each PlaylistsTrackFormat.txt which does not divert from the standard definition. I do not know how it is implemented, whether this is only pointing to the central definition, or some real writing takes place. If the later, yeah than ofc this recursion takes quite some time.
• b) For generating the playlists file/folder structures iTunesFS must look for a PlaylistsTrackFormat.txt in each playlists track or else fall back to the central definition. Also quite some lookup work I guess.

Proposal

• So maybe for users who prefer speed and who do not need different file-formatting per each playlist, you could introduce a flag playlists-can-have-custom-format which by default is TRUE, but those who favor speed could set this to FALSE.

Problem

/Volumes/iTunesFS/PlaylistsTrackFormat.txt
%(artist) - %(album) - %(trackNumber#00) %(name).%(ext.lowercaseString)

For classical music I often only state the composer and leave the artist field empty.
With a stubborn filename formatter I get results like this:

/Volumes/iTunesFS/Playlists/Genre/Classical
- Requiem en ré mineur KV 626 - 04 Tuba mirum.mp3

Proposed Solution

Introduce "if exists bracket" as a new syntax element

• which outputs null if its contained tag evaluates as null
• or else outputs the result of the tag plus any static text before or after

Syntax Idea

• Tag %() — The syntax as it currently is. Outputs the tag value.
• If-exists-bracket *{}
  • If the contained tag evaluates as non-null then output the tag plus free text before or after it.
  • Else output NULL.

Additional ideas

• If-exists-tag *() - Output tag if it exists
• If-else-bracket *{tag plus freetext}{tag2 plus freetext}{tag3}{freetext only as last alternative}
  • If the contained tag evaluates as non-null then output the tag plus free text before or after it.
  • Else try the next curly bracket, which again can be a tag and/or a freetext.
  • An alternative consisting of freetext only is only effective at the last position. As it always evaluates as true all further alternative after it are discarded.

Examples where and how this would help

*{%(composer) - }*{%(artist) - }*(trackNumber#00) - }%(name).%(ext.lowercaseString)

• Composer plus suffix in an If-exists-bracket followed by artist plus suffix in and If-exists-bracket.
• In any permutation you will get a nice output.

*{%(composer)}{%(artist)} - *(trackNumber#00) - }%(name).%(ext.lowercaseString)

• Even more elegant: Composer as the preferred tag, artist as the alternative tag, then separator as freetext.

*{%(artist) - }*{%(album) - }*(trackNumber#00) - }%(name).%(ext.lowercaseString)

• If-exists-tag: If there's no trackNumber its omitted in output entirely.
• A tag-specific handling was created in #3 but the proposed syntax would be the generic solution for this.

%(artist) - *{%(trackNumber#00)}{00}%(name).%(ext.lowercaseString)

• So you will get "Artist TrackNumber Songname" or "Artist || Songname"
• Arthur Band 18 Adulthood.mp3
• Beta Gamma || Adulthood.mp3

Reproduction

• In /Volumes/iTunesFS/AlbumsTrackFormat.txt
  • I tried %(playlistNumber#000) %(artist) - %(album) - %(trackNumber#00) %(name).%(ext.lowercaseString)
  • and later %(playlistNumber#000) %(artist) - %(album) - %(trackNumber) %(name).%(ext.lowercaseString)
• Actual: In both configurations tracks without a track number produce "0".
• Expected: A track not having a track number should produce an empty string.
• Or we could introduce trackNumberNull="" and you can leave this empty or define any custom format you like in the absence of a trackNumber, like "xx" or "•".

Hi there,

when adding songs to a playlist in iTunes, the folder in the corresponding iTunesFS volume doesn't update it's contents.
Only ejecting the volume and opening the iTunesFS app (which remounts the volume) updates the folder contents.
Is there a better way? (hourly auto-update oder a hidden terminal command)
Can't find any options for that.

I read your FAQ, specifically on what you are likely not to implement or surely never going to implement. But as I am not a developer by trade, and not at all familiar with how such virtual/filesystems work I nevertheless make a proposal, more than being rejected cannot happen 😉

Goal

• I want to keep the files in my Music.app unchanged
• I want the possibility for old mp3-players which require a certain ID3 format or the absence of ID3 to get the files transformed when copying.
• Ideally this is implemented in a manner that first iTunesFS only achieves the file listing not taking too much computation,
  • and only if a full read occurs (QuickLook or copy operation to MP3 player) then the operation takes place
  • So theoretically only the ID3 tags portion which needs to be translated on the fly.
  • I would not care if that initial listing lists a wrong filesize (because it is not yet aware of the transformation which occurs later) for the files
  • But ofc, this is how I imagine it idealistically, maybe this is anyhow not feasible.

Proposal

iTunesFs gets additional configuration parameters:

• ID3-conversion: off | on | strip-id3-altogether
• ID3-version = You can state the version number of the ID3 standard to which it should be converted.
• ID3-charset = The character set to which shall be converted.
• Possibly some other parameters get necessary which define what to do in regards to data-loss or data-transformations which need to happen as a consequence.

Carbon Copy Cloner 5.1.28 on macOS 11.6.6 Big Sur

Reproduction

• Source: /Volumes/iTunesFS/Playlists/Devices/mp3player/
• Destination: /Volumes/mp3player/
• I click "Clone". It fails with:

CCC cannot read the contents of the source volume because they are inaccessible to the System Administrator user account.
CCC cannot back up to or from an OS X FUSE volume mounted without the "allow_root" or "allow_other" option.

Possible solutions

• It is comfortable to rsync via GUI as this also keeps a log history and I can easily look up when did I sync last time, how many fiels have it been, etc.
  • Is it possible to change the forementioned flags to what CCC requires?
• If not also ok, then I will simply use rsync in Terminal.