SickGear: a usenet and bittorrent PVR that hands work to your download clients

A television PVR built on the Sick-Beard lineage

SickGear describes itself as a usenet and bittorrent PVR. In plain terms, it is the television half of an automated download setup: it keeps a list of shows, works out when episodes are due, searches for them, and hands the results to whatever download client you already run.

It is a fork of, and descendant from, Sick-Beard, and the README's own framing is that it is the stable and reliable fork of that lineage, with the aim of fully automating television viewing. The repository layout still shows the inheritance clearly: there is a SickBeard.py at the root alongside sickgear.py, the original entry point and the current one.

The scope is television, and the README is consistent about it. Shows and anime are managed, with ideas of what to add coming from Trakt, IMDb and AniDB categories, and separate handling for specials and for multi-episode files. Films are not the subject of the project.

The audience is a self-hosted household or small group running a download client, a media server such as Plex, Emby or Kodi, and one or more indexers, who want the episode fetching automated and who have opinions about how episodes are named, kept and updated.

The project is written in Python, licensed under GPL-3.0, and its most recent releases are 3.36.8, 3.36.7 and 3.36.6 in September 2026, with the last push on 2026-10-05.

The provider layer and its diagnostics

Most of what distinguishes this from a generic search-and-download script lives in how it treats providers, and the README has an unusually detailed list of it.

There is fine-grained selection of which providers to use. You can single out providers to target scene releases either exclusively, with fallbacks to non-scene releases and with optional exclusions, and you can mark providers to avoid scene nuked releases, with an optional fallback when no other choice is available. Underneath is a native regular expression pattern matching system, which the README credits with better information handling than the alternatives.

Then there is the diagnostics, and this is the part that stands out. Provider server failure charts display what failed, when and why, so an empty episode is not a mystery. A failure handler pauses connecting to a server the more it fails, which stops a flaky provider from slowing down every search. A provider server activity graph and statistics display show how each provider is performing over time. And there are integrated IsItDownRightNow buttons for the sites the application depends on, including the television database, TheXem and GitHub, so you can see at a glance whether a site was or is offline.

One more piece of operational detail: secure support of Cloudflare IUAM access with no need to install node.js. That matters because the usual workaround for a challenge page is to bring a JavaScript runtime with you, and the project removes the need for it.

Episode lifecycle, retention and quality rules

The scheduling half of the application has as much configuration as the searching half.

The add show finder is described as advanced, with results that near always come back sorted by A to Z, by aired date or by relevancy, with known shows separated from the unknown ones. When a show is added, releases can be fetched automatically, optionally the oldest and the newest without further effort, so a show added years late does not leave you waiting for a backlog to download one episode at a time. The automated search is a separate feature from the manual one, which is the difference between picking something from a list and not having to look at lists at all.

Retention is configurable per show. Each show can keep all episodes, or any set number of the most recent ones, and the README gives the example of keeping only daily releases from the last 40 days. Quality is handled by a smart custom qualities selector that guides you to an optimal selection for automated search, and you can choose whether episodes are upgraded in quality, whether the existing archive quality is kept, and whether future episodes are upgraded either way.

Episodes also have a status you can set, including for media files that have been removed, which keeps the library view honest after you delete something by hand. The result is a set of rules rather than a switch, and the price is a configuration surface that takes an afternoon to set up properly.

Post-processing and the client integrations

Once an episode arrives, the library side takes over, and the README describes an extensive post-processing pipeline.

Built-in post-processing of episodes handles renaming to custom folder and file names, and metadata is fetched for fanart, poster and banner images along with nfo files for clients such as Kodi, Emby, Plex and Jellyfin. File management covers configurable folder and file renaming for a consistent library and automatic unpacking of rar archives. There is also a change file date option, which sets the file date to the date the episode aired, and the README notes that this feature was created here first, for XBMC file list sorting.

Search results are forwarded directly to clients including NZBGet, SABnzBd, qBittorrent, Deluge and others, or saved to a blackhole folder that a client is configured to scan. The integration with download clients is specific: NZBGet connects directly using a purpose built add-on, and qBittorrent, Deluge, Transmission and similar clients are handled by a dedicated integration script.

The media server side is where the Plex support becomes intricate. Plex server and Plex client settings are separate, multiple LAN Plex servers are supported, and Plex Home multi-user support is included. Library updates are intelligent in a way that matters on a multi-server setup: they target the actual Plex server that carries the show of an episode, rather than notifying every server you have. There is also a choice to delete watched episodes pulled directly from played media at Kodi, Emby and Plex, explicitly without Trakt tracking, and a built-in Kodi repository service for maintaining add-ons, the first of which is a Watched State Updater.

Notifications, subtitles, proxies and the rest of the surface

Beyond the core, the README lists a wide set of smaller features, and they are the ones that decide whether the application fits your setup.

Notifications come in three shapes. Home theater and NAS clients, including Emby, Kodi, Plex, Synology and TiVo, can be notified to update their library. Social notifiers cover Trakt, Slack, Gitter, Discord and email, and device notifiers cover Growl and Prowl. Subtitles are managed automatically, and proxy auto-config is supported, so a PAC file can define when a proxy applies rather than forcing one on every request.

The interface is configurable in ways that are unusual for the category. There is a choice of interface styles, Regular, Proview I and Proview II, set independently for the daily schedule and for the display show view. The fanart system can be rated to avoid or prefer, the fanart interface can be moved or switched off, and a day by day schedule layout shows fanart backgrounds for imminent releases. Fanart caching is configurable from zero to 500 images per show, with a default of three.

The search itself is described as server friendly, with a minimal number of API calls using both active and passive search technology, and there is automated handling of failed downloads to ensure success after a failure, plus alternate show names and episode numbering pulled from XEM.

The home page is configurable, and the visual progress of managed episodes is shown as a percentage. A large application with a large surface is what you are signing up for.

Installing, running and the packaging around it

The installation instructions are not in the README, and that is deliberate. The README points at the wiki, with an installation page covering many platforms, and a separate migration page for moving from the 0.x releases to the current feature set, described as a hassle free upgrade.

The repository itself shows what a deployment looks like. There is an init-scripts directory, which is the conventional place for the service definitions that start the application on a Unix-like system, and a snap directory, which is a packaging format that installs the application with its dependencies and a confinement profile on a Snap-equipped system. The entry points sit at the root, with sickgear.py as the current one and SickBeard.py carried from the fork's ancestry, and _cleaner.py for cleanup work.

The Python dependencies are declared in a requirements file, and it contains a single entry:

CT3

The README's own claims about the project sit alongside that. Testing and development are described as stable and quality assured, with a tox.ini at the root for the test configuration and a .codeclimate.yml for static analysis, plus a .gitlab-ci.yml for continuous integration. A recommended.txt and a recommended-remove.txt at the root are lists of packages the project suggests installing and removing, and HACKS.txt records the manual interventions that the automation cannot make.

That last file is worth reading before deploying. It is the honest inventory of the places where the application expects a human to have done something.

Where SickGear is the wrong tool

The first limitation is genre. This is a television tool. If what you want is films, a different PVR built around a film database is the right shape, and the episode scheduling, the season and episode numbering and the airing dates that SickGear is built around do not apply.

The second is that the automation depends on parts you do not control. Providers come and go, indexers change their interfaces, and challenge pages appear. The project's own diagnostics are the answer to that reality rather than a fix for it, and the honest reading of the failure charts and the IsItDownRightNow buttons is that this application expects occasional attention.

The third is the configuration weight. The feature list is long enough that a first-time user faces dozens of decisions before the first episode downloads, and the wiki, rather than the application, is where that knowledge lives. The README's argument that SickGear has the least issues and the least number of changes that require further fixes is a claim by the project about its own development, not a guarantee that it is simple.

The fourth is the documentation. There is no manual in the repository, only a wiki, and a wiki that is maintained from user feedback can lag behind a release. The CHANGES.md file at the root is the changelog, and the release tags are named release_3.36.x, so tracking what changed between a documented behaviour and your installed version means reading the changelog rather than release notes.

Finally, the licence. GPL-3.0 with a COPYING.txt at the root, which is the right choice for a tool that is patched and extended by its users, and a constraint for anyone who wants to fold it into a closed product.

Editorial conclusion

Adopt SickGear if you follow television series, you already run one or more download clients, and you want episode automation with provider health visibility rather than a generic downloader. Do not adopt it for films, since the project is built around television scheduling, and do not adopt it without a working indexer setup, because the automation is only as good as the providers behind it. Verify first that the providers you rely on are in the current list in the wiki, that the release you install matches the branch you are reading documentation for, and that the client integrations you need exist in the built-in set rather than in a script you have to write yourself.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. SickGear/SickGear on GitHub