Skip to content

Pipeline And Storage

Weaver separates durable state from in-progress work and finished output, and runs every job through the same stages. These terms describe the directories and the stages.

The data directory holds the database, stored NZBs, API keys, RSS state, the scripts folder, and internal state. It is /config in Docker, %LOCALAPPDATA%\weaver on Windows, and the path given to --config elsewhere. Keep it on persistent storage and back it up.

The intermediate directory holds each job’s in-progress work. It defaults to <data directory>/intermediate and is set in Settings → General. Fast local storage suits it.

The complete directory receives finished output, under a category subfolder when a category is set. It defaults to <data directory>/complete. Point it somewhere the tools that consume finished downloads can see. See Storage Layout.

Cleanup After Extract removes archive volumes after a successful extraction so only the extracted result moves to the complete directory. It is a switch in Settings → General.

Max Retries is how many times a failed article fetch is retried before the job counts the article as missing. Repair covers what retries cannot.

Every job passes through download, verify, repair when damaged, extract, and move, then optional post-processing scripts. The stages are always Weaver’s own work, never a script.

Verification uses the PAR2 set at the block level as articles decode, so a clean job finishes verified without re-reading the download. Jobs without PAR2 are checked against an SFV file when one is present. Repair and extraction are built in. Extraction runs while the download is still in progress. See Weaver vs. SABnzbd And NZBGet.

Direct store writes the bytes inside a stored RAR set straight to the final extracted files as they download, so the archive volumes never exist on disk. It is on by default, decided per archive set, and falls back to the conventional path automatically. 7z sets have an opt-in equivalent, direct unpack, enabled with [direct_unpack] enabled = true in Weaver’s TOML config. See Direct Store.

Move delivers the finished output to the complete directory. Weaver renames when source and destination share a filesystem and copies when they do not, which is why the intermediate and complete directories are best kept on one filesystem.

A delivered file that still wears an obfuscated name is renamed to the job’s name. That is on by default. An optional lookup against the public srrdb release index can recover the original release name first, and it is off by default because it reaches outside your network. Both switches live under [delivery_naming] in Weaver’s TOML config.

Unacceptable extensions, configured under Settings → Post-processing, fail a job whose output matches a pattern such as *.exe, once Weaver has a trustworthy output name.

A post-processing script is a file, or a folder with an NZBGet manifest.json, placed in the scripts folder inside the data directory. Weaver lists the folder live, so adding or editing a script needs no import.

Scripts run under the environment contract their ecosystem expects: SABnzbd’s SAB_* variables and positional arguments by default, or NZBGet’s NZBPP_* and NZBPO_* variables and 93, 94, and 95 exit codes when the script carries NZBGet’s header or ships a manifest. Existing scripts run unmodified. Execution is off until enabled in Settings → Post-processing, and refused outright under WEAVER_STRICT_SECURITY.

A script list is the ordered set of scripts a job runs: one global default and an optional override per category. The list is resolved when the job finishes, entries can be disabled without removal, and each carries its own timeout. Results are recorded on the job and shown in Job Detail. See Post-Processing Scripts.