Jobs And Queue
An NZB goes in, a job comes out, and the queue is where you watch it. These terms describe that path.
Instance
Section titled “Instance”An instance is one running Weaver server with its own database, settings, storage paths, queue, and web UI. A Docker container with /config and /downloads mounted is one instance. SQLite is the default database, and PostgreSQL is supported through WEAVER_DATABASE_URL.
An NZB is the file that describes a Usenet post: which articles to fetch and which files they form. Weaver accepts .nzb and .nzb.xz files through Upload, the watch folder, RSS, and the API, and keeps a copy with the job.
The job name comes from the filename or the NZB’s own title, with release metadata stripped. A password embedded in the NZB or entered at upload travels with the job for encrypted archives.
A job is one NZB’s unit of work: download, verification, repair, extraction, move, and scripts. Every page in the app is a view of jobs.
Statuses in order of a normal run: Queued, Downloading, Checking while a health probe confirms the articles exist, Verifying, Queued for repair and Repairing when needed, Queued for extract and Extracting, Moving, Queued for post-processing and Post-processing when scripts are configured, then Complete or Failed. Paused can interrupt any of them.
Priority
Section titled “Priority”Priority is Low, Normal, or High. It is set at upload, changed inline or in bulk from the queue, and honored by the NZBGet-compatible API. Higher priority jobs are dispatched first.
The queue is the live list of active and paused jobs, at the root route and as Queue in the left navigation. It carries the queue-wide controls: Pause All and Resume All, the speed limit, upload, and bulk edit of priority and category.
Banners explain why jobs hold position: Downloads paused, ISP cap reached, Server quota exhausted on every eligible server, or No servers configured.
Upload
Section titled “Upload”Upload stages one or more NZB files with a shared password, priority, category, and duplicate handling, then creates one job per file. Reach it from the persistent Upload button. Staged files expire if left unsubmitted.
Category
Section titled “Category”A category is a named label with an optional destination directory and comma-separated aliases. Without an override, a category’s jobs land in <complete directory>/<category name>/.
Submissions name categories loosely, so matching is forgiving: an exact case-insensitive name match first, then a glob match against aliases with * and ?. Categories are managed in Settings → Categories and used by Upload, RSS rules, the watch folder, and API clients.
Duplicate Handling
Section titled “Duplicate Handling”Weaver fingerprints every submission by its article layout and normalized name. Settings → General → Duplicate Handling decides what a match does per fingerprint class: Accept, Warn and accept, Accept paused, or Block. Upload and the API can override the mode for one submission, including Force submission to bypass the policy.
Job Detail
Section titled “Job Detail”Job Detail is the page for one job: progress, size, saved bandwidth, speed, output files, metadata, and the event log with every pipeline decision and script result. Open it from any queue or history row. Single-job actions live here: pause, resume, cancel, delete, reprocess, re-download, and re-run scripts.
History
Section titled “History”History is the record of complete and failed jobs, separate from the queue. Rows can be deleted singly, in bulk, or all at once, optionally deleting the downloaded files too. Destructive history operations need admin scope over the API.
Reprocess runs the pipeline again over a retained job’s downloaded data. Re-download submits the stored NZB as a fresh download. Re-run scripts repeats the post-processing script list against the finished output.
Related
Section titled “Related”- Queue And History walks the pages these terms appear on.
- Pipeline And Storage explains what happens between Downloading and Complete.