Decypharr: Delete Symlinks Without Re-search Feature
Hey guys! Let's dive into a really cool feature request for Decypharr that could seriously streamline how we manage our media libraries. This suggestion focuses on giving users more control over the repair process, specifically when it comes to symlinks and re-searching for content. So, let's get into the details and see why this could be a game-changer for many of us.
The Problem: Current Re-search Behavior in Decypharr
Currently, Decypharr's repair function, while super helpful, has a quirk that can sometimes cause a bit of a bottleneck. When it identifies broken symlinks, it not only deletes them but also immediately kicks off a re-search for all the missing content in Sonarr or Radarr. Now, while this sounds efficient in theory, the practical implications can be a tad frustrating.
Imagine this: you've got a bunch of symlinks that need fixing. Decypharr dutifully deletes them, and then bam, it floods Sonarr with a ton of search requests all at once. This surge of searches can lead to a massive queue, and Sonarr gets bogged down trying to process everything. The real kicker? Sonarr won't start importing any content until all those searches are done. This means you're stuck waiting, and nobody likes waiting, right?
To really understand the impact, let’s break it down. The core issue here is the simultaneous re-search initiation. This action, while intended to quickly replace missing files, inadvertently creates a backlog. Think of it like a traffic jam on the information superhighway. All the search requests are piling up, and nothing is moving until the congestion clears. For those of us with large libraries or slower connections, this delay can be a major headache. We want our content, and we want it now (or at least, reasonably soon!).
The problem isn't just about speed, though. It's also about control. Sometimes, we might have specific reasons for wanting to manage searches ourselves. Perhaps we have a preferred search method, or we want to stagger the searches to avoid overwhelming our systems. The current behavior of Decypharr takes away some of that control, forcing us into a one-size-fits-all approach. And as we all know, one size rarely fits all in the world of media management.
Proposed Solution: A Toggle for Symlink Deletion Without Re-search
So, what's the fix? The suggested solution is brilliantly simple: add a toggle in Decypharr that allows users to delete symlinks without automatically triggering a re-search. This seemingly small addition could make a world of difference in how we handle repairs. It's about giving us, the users, the power to choose what works best for our individual setups and preferences.
Think of this toggle as a switch that lets you customize Decypharr's behavior. Flip it one way, and you get the current functionality – delete symlinks and immediately start the re-search. Flip it the other way, and you get the new, more granular control – delete symlinks and… well, that's it. No automatic re-search. This means we can then use other tools or methods to manage the search process, giving us the flexibility we crave.
But why is this so important? Let's dig a little deeper. For many of us, our media libraries are carefully curated ecosystems. We might use specific services or tools to handle different aspects of media management. For instance, some users, like the one who submitted this feature request, rely on services like Huntarr to manage searches for missing content. Huntarr, in this context, becomes a specialized tool that offers more tailored search capabilities than the default Decypharr re-search.
By having the option to disable the automatic re-search, we can seamlessly integrate Decypharr with these other tools. We can let Decypharr handle the symlink cleanup – its core competency – and then hand off the search task to Huntarr or any other preferred service. This creates a more harmonious workflow, where each tool does what it does best, and we, the users, get the benefit of a well-oiled machine.
Furthermore, this toggle isn't just about integrating with other services. It's also about giving us more control over our system resources. As we discussed earlier, the simultaneous re-search can strain Sonarr and lead to delays. By disabling the automatic re-search, we can stagger the searches, preventing our systems from getting overloaded. This is particularly crucial for those of us running on less powerful hardware or with limited bandwidth. It’s about optimizing our resources and ensuring a smooth, efficient experience.
Benefits of the Proposed Solution
Let's recap the awesome benefits this feature would bring to the table:
- More Control: You get to decide when and how searches are initiated.
- Integration with Other Services: Seamlessly use Decypharr with tools like Huntarr.
- Reduced Sonarr Queues: Avoid overwhelming Sonarr with simultaneous searches.
- Optimized Resource Usage: Stagger searches to prevent system overload.
- Faster Import Times: Get your content imported sooner by managing searches effectively.
In essence, this feature is all about user empowerment. It's about recognizing that we all have different needs and preferences, and giving us the tools to tailor our experience accordingly. It's a small change, but it has the potential to make a big impact on the way we manage our media libraries.
Alternative Solutions Considered (or Not!)
Interestingly, the user who requested this feature mentioned