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
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:
The "Albums" file/folder structure is strictly hierarchical, every item occurs only once.
Albums have only one central format definition at /Volumes/iTunesFS/AlbumsTrackFormat.txt
The "Playlists" file/folders structure is much more heterogenous, items can occur multiple times, smart playlists can produce massive result lists.
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.
The text was updated successfully, but these errors were encountered:
This is a Finder problem. It could probably be solved by sending [[NSWorkspace sharedWorkspace] noteFileSystemChanged:<path>] when reloading the library's contents, but this would require more than minor internal reorganization. It wouldn't work with IFSiTunesFrameworkLibrary as Apple's framework doesn't notify when changes occur, so this wouldn't even work for macOS >= 10.15.
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
/Volumes/iTunesFS/AlbumsTrackFormat.txt
/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
/Volumes/iTunesFS/PlaylistsTrackFormat.txt
/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:
/Volumes/iTunesFS/AlbumsTrackFormat.txt
/Volumes/iTunesFS/AlbumsTrackFormat.txt
plus an overridePlaylistsTrackFormat.txt
at each playlist folder within/Volumes/iTunesFS/Playlists/*
./Volumes/iTunesFS/AlbumsTrackFormat.txt
this change is (virtually) written to eachPlaylistsTrackFormat.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.PlaylistsTrackFormat.txt
in each playlists track or else fall back to the central definition. Also quite some lookup work I guess.Proposal
The text was updated successfully, but these errors were encountered: