Repair

Repair in Zurg

Context

• Configuration-Dependent Invocation: The repair process in Zurg is contingent upon a configuration setting (enable_repair). If repair is enabled, RepairAll() is invoked by the periodic refresh job to initiate the repair process. Conversely, if repair is disabled, the process is skipped.

Triggers

• Initial Repair: On the initialization of TorrentManager (as detailed in internal/torrent/manager.go), a check is made to determine if the repair functionality is enabled. If so, RepairAll() is invoked for an initial repair check.
• Periodic Refresh and Repair: In internal/torrent/refresh.go, the startRefreshJob() function implements a periodic process that refreshes the torrents' state. After each refresh, if repair functionality is enabled, RepairAll() is called, linking changes or updates in the torrent state with the repair process.
• During File Access: When Zurg encounters an error while accessing a file, it sets the file's link to empty, triggering the periodic refresh to immediately invoke the repair process.

Process

1. Initiating Repair:

   • Executed through RepairAll(), either after a periodic refresh or during initialization, depending on the configuration setting.

2. Identifying Torrents to Repair:

   • The repairAll() function identifies torrents that need repair based on several checks:
     • Uncached Torrents: Torrents not cached are first identified.
     • Torrents with Broken Files: Torrents with files that lack a valid HTTP link and are not marked as 'unselect' (deleted files).
     • Torrents with Unassigned Links: Unassigned links are download URLs that couldn't be matched to any of the selected files within a torrent.

3. Repairing Individual Torrents:

   • For each torrent identified for repair, Repair(torrent *Torrent) is invoked.
   • The function first checks if the torrent is already under repair, in progress, or unfixable. If so, the repair process for that torrent is bypassed.
   • Managing Broken Links: If there are broken links, the system attempts to fix them by reassigning or redownloading these links.
   • Capacity Check: The system verifies if there is capacity to handle the repair process; if not, it waits until there is.
   • Torrent Redownload: The torrent may be completely or partially redownloaded, specifically targeting the broken files.

4. Finalizing Repair:

   • After attempting repairs, the system checks if the issues are resolved. If unresolved, the torrent might be marked as unfixable.
   • Torrents that are irreparable (e.g., torrents rar'ed by RealDebrid) are either deleted or marked as unplayable, according to the configuration settings.

Other Details

• Repair Pool Management: The repairPool (always has 1 worker) is used to manage and execute repair tasks asynchronously.
• Broken Files Handling: The system identifies broken files and clears their links, indicating the need for repair.
• Torrent Redownload Strategy:
  • Method 1: Attempts to redownload the entire torrent to repair files (repair_method#1). If successful, the process is terminated.
  • Method 2: If the first method fails, the system attempts to redownload only the identified broken files (repair_method#2).
• Capacity Handling: Implements a retry mechanism to handle the maximum number of active torrents, waiting for a window to proceed with the repair.
• Status Check and Cleanup: Continuously monitors the status of the torrent and performs necessary cleanup operations if repair attempts fail or if a torrent is deemed unfixable.
• File Link Assignment: Assesses and reassigns links to the files within a torrent during the repair process, particularly focusing on size matching for accuracy.
• Unplayable and Unfixable Torrent Management: Marks torrents as unplayable or unfixable based on specific criteria, such as being rar'ed by RealDebrid or having infringing files.