-
-
Notifications
You must be signed in to change notification settings - Fork 424
Description
Checklist
- I am using an up-to-date version.
- I have read the documentation.
- I have searched existing issues.
Description
Relinking when many entries are unlinked takes a long time. While I cannot find the code responsible for this (perhaps it is in a dependency, a Windows limitation, or just how the scale of my library), it appears the rate is about 1 item every 3 seconds.
While relinking should be smarter (#36), cancel-able (#1212), and be able to be done manually (#923), search time remains a limiting factor for the job. In this feature request, I will outline some potential optimizations.
Solution
Relink Metadata Index
In the entry index, add information about whether an entry already tried and failed to relink. This occurs in the following scenarios: relink canceled (not yet implemented), application closed/crashed or OS interruption, user did not remove entries that failed to relink.
With this information, more advanced relink options can be added, such as only attempting to relink items that have not been attempted before, and only deleting entries that have already failed.
Library-only mode
Rather than searching the library filesystem fully, allow a "quick scan" that checks if any new library entries (added after the link failed) are the missing items.
Alternatives
Implementing the existing feature requests previously mentioned are highly desirable, but do not directly address the speed of the file scanning.