Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Albums refresh very instantly after changes to their config file whereas Playlists refresh only minutes later #2

Open
porg opened this issue May 30, 2022 · 1 comment
Labels

Comments

@porg
Copy link

porg commented May 30, 2022

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.
@znek
Copy link
Owner

znek commented May 31, 2022

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.

@znek znek added the wontfix label May 31, 2022
@znek znek mentioned this issue May 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants