Skip to content

[Feature Request]: relink optimiztions #1218

@mm12

Description

@mm12

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions