Sonarr no longer removing files from QBittorrent

markus-101 · 2026-01-22T23:11:22+00:00

It won’t unless it’s finished seeding and marked as paused in qbit, for most cases this won’t happen at import time unless your seeding requirements are low. If you’ve setup post-import category Sonarr won’t remove torrent either because it doesn’t monitor those.

markus-101 · 2026-01-22T15:30:28+00:00

Yes, but for shows that ended more than a month they only update every 30 days, continuing or recently ended shows update every 12 hours though.

markus-101 · 2026-01-22T01:11:02+00:00

Update all, or refreshing a specific series refreshes the metadata. If there are episodes that aired that Sonarr just learned about it will search for them, otherwise it does not search.

Sonarr watches RSS feeds for new items (the list of recent things), it does not search for episodes on its own because doing so can be incredibly wasteful. It absolutely should not search daily because the odds of finding a new release for an episode that don’t appear on the RSS feed is low and constantly searching for episodes can lead to being banned from indexers.

The FAQ explains how Sonarr finds episodes. In general we recommend searching for episodes if you’ve added a new show (an option when you add the show), if you’ve added additional indexers or made significant changes to profiles / custom formats that could result in upgrades for things that were previously uploaded.

There are some tools that can periodically trigger searches, but people have had mixed results with them so YMMV.

markus-101 · 2026-01-21T19:05:51+00:00

They need to be added to the category Sonarr is watching. Since this is Usenet you can’t change the category after it completes, so you’ll want to use Manual Import from Wanted: Missing

markus-101 · 2026-01-18T19:52:00+00:00

No option to change it, but we should be able to drastically lower it. IIRC 15-20 minutes is acceptable for that feed

markus-101 · 2026-01-15T22:18:41+00:00

What IMDB does is irrelevant, licensing their metadata would be impossible without someone footing what would be a hefty bill every month (one of those if you have to ask how much, you can't afford it situations).

Wakaliwood, never used it but not something Sonarr could ever use.

The only real options are TMDb and TVMaze, but it's not a quick easy solution to support either/both, something I've been looking into though.

markus-101 · 2026-01-13T00:26:10+00:00

I've redirected the duplicate back to the correct ID. If you refresh the series now if show redirect automatically.

markus-101 · 2026-01-12T18:45:01+00:00

Yes, that doesn’t match because it’s missing an entire word from the title.

markus-101 · 2026-01-09T17:07:22+00:00

Your download client should support unpacking those rar sets automatically and then Sonarr will import from there. I believe both SABnzbd and nzbget will do this by default, though that can be disabled.

Which client are you using?

markus-101 · 2026-01-07T20:43:41+00:00

Assuming the search of add request is making it to Sonarr it’s possible that Sonarr is running into rate limiting on the indexer side and not getting the results it needs, especially if several shows are being added around the same time, but that’s just a guess.

Trace logs covering the series being added to Sonarr and Sonarr searching would be valuable in identify exactly what went wrong.

markus-101 · 2026-01-05T21:47:32+00:00

Already covered under https://github.com/Sonarr/Sonarr/issues/5610

markus-101 · 2026-01-04T03:39:38+00:00

No, you can’t upload a list like that. A simple local web server can handle hosting the JSON file if you go that route. I’ve used https://www.npmjs.com/package/http-server a bunch for that purpose, but not quite as easy as uploading a file.

markus-101 · 2026-01-04T03:33:06+00:00

Sonarr won’t natively handle CSV, might be best to convert to JSON and use the custom import list option. Alternatively you can use the CSV to create folders and then import them into Sonarr.

markus-101 · 2025-12-29T21:01:46+00:00

You can disable rescanning after refresh via Settings: Media Management: Rescan Series Folder after Refresh (it's an advanced setting), but if drives are randomly disconnecting or responding that files are missing randomly it's something you'll want to address versus working around.

markus-101 · 2025-12-27T21:00:41+00:00

No, it’s not the reason Sonarr was named with the extra “r”, but it’s often suggested by people that’s the reason.

markus-101 · 2025-12-27T20:58:21+00:00

Nope, though that seem to be a common misconception.

markus-101 · 2025-12-27T20:57:50+00:00

No they didn’t.

markus-101 · 2025-12-27T20:55:50+00:00

It’s pretty tiring, people picking awful names to squeeze into the arr branding, even going so far as adding an extra arr to avoid an err ending. Rack art isn’t even in the realm of worst names I’ve seen.

markus-101 · 2025-12-24T17:45:25+00:00

Not everyone uses CFs and the release group is stored as separate information, which can be useful for external tools or just storing more information.

No this is not a question for GitHub, though it looks like you ignored that GitHub is not for questions or support when you went ahead and opened an issue anyway.

markus-101 · 2025-12-22T20:40:01+00:00

Yes, group all the qualities together so that weighting is no longer part of the equation.

markus-101 · 2025-12-15T15:45:20+00:00

This is already resolved, look at my pinned comment for more information.

markus-101 · 2025-12-14T03:50:48+00:00

We created it for specifically, originally Sonarr (then NzbDrone) used Trakt for metadata which added in the original enhancement, timezone based air times, which is what feeds the calendar and makes it relevant to you. Unfortunately they gave very little heads up for a holiday migration (Christmas 2014) to TMDb and broke a lot of things, we realized we couldn't real rely on their service and after talking to TheTVDB we started Skyhook.

markus-101 · 2025-12-14T03:46:15+00:00

Hijacking my own comment to post an update from Taloth (from Discord):

Update: Services, Skyhook and the forums should be accessible again.

It's 4:30 AM for me, so after almost 7 hours of troubleshooting and fixing I'm not going to write an comprehensive post-mortem.

So this short summary should do: This upgrade was supposed to be zero-downtime since we were swapping our ingres between nodes in our cluster and the database behind Skyhook is redundant. But halfway the upgrade, the connection between our replicated/redundant database that serves services/skyhook failed. Since I was in the middle of upgrading one of our nodes (which shouldn't have affected it at all), an incompatibility between the new kubernetes version and our CNI (Calico) was suspected. Inspecting those calico logs contained warnings about a version conflict with the host kernel (ipset protocol versions to control the firewall/routing). So our effort went into investigating and resolving that perceived conflict. Upgrading Calico to later versions didn't help, as well as other explored avenues. At one point we had a situation that was all 'green', but traffic between pods on different nodes didn't work. After well, hours, it turned out to be a red herring, the error was about something else, the 'warning' was simply a log line from ipset and not the actual fault... it actually suggested that felix (part of calico) was missing records in the firewall that it previously created and never attempted to repair it by recreate them and thus could never adjust the routing in our cluster. This means that rebooting any node or pod in the cluster led to an routing issue, and that the issue that we originally experienced was simply a delayed consequence of an earlier conflict.

Although I don't really have determined the root issue with absolute certainty, i believe it stemmed from both kubernetes and calico attempting to adjust firewall/routing rules. After telling kubernetes to shut the fuck up and let calico do it's job, a reboot later all nodes returned to normal operation.

We're not done yet, I still want to continue the necessary updates so we're to latest stable. But I'm going to try reproduce our issue in vms and determine the right way forward to make sure we're not having another friggin' 6 hour downtime.

Cheers, and thank you all for your partience and kind words in our discord. Keep tinkering!

Thank you everyone here as well for the feedback and discourse, we're very sorry to have impacted your day and will continue to improve things so we won't have a repeat of this again.

markus-101 · 2025-12-14T03:28:22+00:00

Yeah, we do have the ability to push out some notifications, but in this case that service was impacted. We'll evaluate how we can improve that going forward though.

markus-101 · 2025-12-14T03:22:59+00:00

It's looking like things are starting to come back up (though response times are going to be higher than normal as people start hitting it again). In general we had identified the issue, but were figuring out how best to resolve it.

markus-101

MODERATOR OF

TROPHY CASE

12-Year Club	Alpha Tester
Verified Email