[{"content":"If you have priced up Usenet providers for more than five minutes, you have noticed the same thing I did: almost every \u0026ldquo;comparison\u0026rdquo; is really a list of brands, not networks. Eweka, TweakNews, Newshosting, NewsgroupDirect, UsenetExpress, ViperNews — they sound like rivals. Most of them are not. They are shopfronts, and underneath sit a handful of actual storage backbones that do the work. Get the backbone wrong and no amount of brand familiarity saves you; get it right and the rest is just price.\nThis guide does the comparison the roundups skip: Omicron vs UsenetExpress — the two backbones that matter most to a UK user in 2026 — compared honestly on retention, completion, speed, price and who each is actually for. Where I name a provider, it is because it earns it.\nAffiliate disclosure: this page contains affiliate links. If you sign up through them this site may earn a commission — at no extra cost to you. It never changes what gets recommended or how anything is ranked.\nIf you are new to the whole system, read What is Usenet and how does it work? first — this page assumes you know what an article, an NZB and a provider are. For the wider provider landscape, the Best Usenet Providers UK 2026 roundup is the parent page; this is the deep dive on the single most important choice inside it.\nWhat a \u0026ldquo;backbone\u0026rdquo; actually is A backbone is the storage network: the servers that physically hold the articles, however many petabytes deep, for however many days. A provider is the account you buy. Most providers do not run their own backbone — they resell someone else\u0026rsquo;s, often with a different logo and a different price for identical storage.\nThree independent storage networks dominate the UK-facing accounts you will meet in 2026 — plus a fourth spool, Giganews-backed Supernews, which you mostly meet bundled inside multi-backbone deals rather than as a standalone pick:\nBackbone Who runs on it Best known for Omicron Eweka, TweakNews, Newshosting, dozens of resellers Biggest spool, deepest retention UsenetExpress UsenetExpress, NewsgroupDirect, ViperNews, resellers Fast, modern, strong completion Abavia Usenet.Farm, a handful of resellers Classic independent European spool Giganews Supernews (mainly bundled in multi-backbone deals) Long-standing spool, rarely sold alone Pick the backbone first, then shop resellers on price and features. The brand on the website means almost nothing; the spool behind it means everything. Two providers with totally different names can sit on the same Omicron storage and be, functionally, the same product at two prices. That is the single most useful fact in this entire article, so I will keep coming back to it.\nOmicron: the deep-spool giant Omicron is the 800-pound gorilla of Usenet. It is routinely mislabelled \u0026ldquo;Abavia\u0026rdquo; in forum threads, but the two are separate — and Omicron is far larger. Eweka, Newshosting, TweakNews and a long tail of resellers all draw from it.\nStrengths:\nThe deepest binary retention in the business — around 15 years on the deepest front-end (Eweka) and roughly 11 years on Newshosting. If a post is old, Omicron is where it is most likely to still exist. Enormous spool size. More raw storage than anyone else, which is precisely why the retention figure holds up. Choice of front-ends. Because so many resellers sit on it, you can pick your price, your connection count and your billing quirks without leaving the storage network. Weaknesses:\nReseller noise — and markup. Dozens of providers selling the identical spool at wildly different prices. Buying from a white-label middleman is just paying a brand tax for the same articles. Buy near the source. Price floor is higher on the Eweka-tier front-ends, because you are paying for depth you may never touch. Connection caps on some front-ends. Eweka, for example, caps connections at around 20, which can bottleneck a fast full-fibre line — check the cap before buying if you are on gigabit. Completion is excellent but not magic. Deep retention does not mean every old post is complete — retention and completion are different numbers, and I will explain why that matters in a moment. Pick Omicron if: you chase old, rare or archive material, you want the maximum chance a decade-old post still resolves, and you would rather pay a little more for depth.\nUsenetExpress: the fast, modern completion play UsenetExpress is a newer, independently-built backbone — and it is the one more UK users should probably default to in 2026, especially on a budget. UsenetExpress, NewsgroupDirect and ViperNews all run on it (NewsgroupDirect and ViperNews share an owner with the backbone itself).\nStrengths:\nExcellent completion on a single coherent spool. Because the network is modern and self-contained, the articles it does hold tend to be complete. For recent and mid-age releases, it frequently matches Omicron on actual completion at a lower price. Genuinely competitive pricing — tiered unlimited plans land around the $8/month mark, and the real edge shows up on blocks: roughly $0.04–$0.10/GB, among the cheapest genuinely-good per-gigabyte pricing anywhere. Note the entry-tier gap is narrow now — Newshosting (Omicron) runs about $99/yr (~$8.25/mo) on promo — so UsenetExpress pulls clear on block pricing and against the pricier Omicron front-ends (Eweka sits in the low double-digit GBP), not on raw monthly cost alone. Fast. Clean, modern infrastructure with high connection counts on the good front-ends, so it soaks up a fast UK line without choking. Weaknesses:\nShallower retention — roughly the 5,000-day mark. For modern downloads that is plenty; for genuinely ancient archives it is a genuine limitation next to Omicron\u0026rsquo;s up to 15 years. Less depth on truly old, unpopular posts, where the long tail thins out first. Pick UsenetExpress if: you download mostly recent or mid-age content, you care about completion and price more than archive depth, and you want the best value-per-gigabyte without overpaying for retention you will not use.\nOmicron vs UsenetExpress — head to head Omicron UsenetExpress Retention ~11–15 years (front-end dependent) ~5,000 days Completion (recent) Excellent Excellent — often equal Completion (ancient) Best available Good, but thinner Speed Very good Very good — modern infra Entry price Eweka-tier much higher; Newshosting near-promo ~$8/mo tiered; cheapest block $/GB Best for Archive depth, old/rare posts Modern use, best value Main risk Paying for depth you don\u0026rsquo;t use Hitting a wall on old posts The honest summary: Omicron wins on age, UsenetExpress wins on value. For the overwhelming majority of what a normal person downloads — new releases, recent TV, current files — the two are close enough on completion that price should decide it, and that usually points to UsenetExpress. The only scenario where Omicron is clearly worth the premium is when very old material is a real part of your diet.\nThe number that matters more than retention Here is the thing the marketing fights to hide: retention is how long an article is stored, not how complete it is when you pull it. A provider can advertise 6,000 days and still hand you a file that is 98% complete because the final chunk aged out, was taken down, or never propagated.\nThat gap is where completion lives, and completion is what actually decides whether you get a usable file. And completion links straight to the repair budget: Usenet releases ship with only 5–10% PAR2 parity — recovery data that can rebuild missing pieces, but only up to that percentage. If a spool leaves you missing more than the parity covers, no repair can save it, however many times you retry.\nSo the real question is not \u0026ldquo;how many days of retention?\u0026rdquo; but \u0026ldquo;how much of this release will actually complete, and will my PAR2 budget cover the rest?\u0026rdquo; That is why a backbone with slightly shallower retention but better completion often beats the \u0026ldquo;biggest spool\u0026rdquo; brand — and why the PAR2 repair guide is the natural companion to this page. Retention sets the stage; completion and PAR2 decide the outcome.\nThe pro move: run both You do not actually have to choose. The most reliable setups run one backbone as the main account and the other as a fill server — a second provider your downloader falls back to, silently, for anything the first cannot complete. Because Omicron and UsenetExpress hold genuinely different copies of the world, a file that is missing on one is frequently complete on the other. That is how people push completion from roughly 96% to 99%, and that last few percent is exactly where stubborn, old and niche files live.\nThe cheap way to do it is a block account on the second backbone: prepaid, never expires, and you only spend when your main provider comes up short. A £10–£15 block on the other backbone is, for many people, the entire annual Usenet bill — and the best insurance you can buy against a download dying at 98%. The mechanics are in the block accounts explained guide; the pricing comparison is in cheapest Usenet providers.\nThe neat detail for UK readers: NewsgroupDirect\u0026rsquo;s Grand Slam account spans four backbones in one login — its own UsenetExpress spool plus Supernews, Usenet.Farm (Abavia) and ViperNews — with deep multi-backbone retention and 100 connections. That is the multi-backbone answer in a single account, which is why it is the one I point people to below.\nThe UK angle Two things matter more in the UK than most US-centric guides admit:\nISP behaviour. Some UK ISPs throttle or shape Usenet traffic on standard ports. Connecting on SSL port 563 to a provider with good UK peering keeps you out of the slow lane, and both Omicron and UsenetExpress front-ends support it. If you suspect throttling, the UK ISP throttling angle is worth ten minutes. Indexers are the other half. A backbone only holds what its spool has seen. A good indexer tells you before you download whether a release is likely to complete — see Usenet indexers explained. Backbone and indexer together decide your completion rate; neither does it alone. The honest recommendation For a UK user in 2026 downloading mostly modern content, UsenetExpress is the better default — equal completion on recent posts at a meaningfully lower price, with the depth you are giving up being depth you probably never touch. Reach for Omicron only if old, rare or archive material is genuinely part of your diet, in which case the depth is worth the premium.\nBest of all, you rarely have to pick one: make your main account whichever suits you, then add a cheap block on the other backbone as a fill server and let your client chase the last few percent automatically.\n👉 Grab a NewsgroupDirect account here — unlimited on the UsenetExpress backbone, or a never-expiring block you can run as the fill server behind whatever you already use. Its multi-backbone coverage is exactly the \u0026ldquo;run both\u0026rdquo; strategy in one signup.\nFAQ What is the difference between Omicron and UsenetExpress? They are two genuinely separate Usenet storage backbones. Omicron is the largest network, with the deepest binary retention (up to ~15 years) and dozens of resellers. UsenetExpress is a newer, independently-built backbone with shallower retention (~5,000 days) but a fast, coherent spool and strong completion on recent and mid-age posts. In short: Omicron wins on age and depth, UsenetExpress wins on speed and price for typical modern use.\nWhich backbone is better, Omicron or UsenetExpress? Neither is universally better — it depends on what you download. If you chase very old or obscure archives, Omicron\u0026rsquo;s depth is unmatched. If you download mostly recent releases and want the best price-per-completion, UsenetExpress is often the smarter buy. Many experienced users run one as their main account and a block on the other as a fill server, so they get both.\nIs UsenetExpress as good as Omicron? For recent content, often yes — UsenetExpress frequently matches or beats Omicron on completion for posts within its retention window, at a lower price. It falls behind only on genuinely ancient archives, where Omicron\u0026rsquo;s much deeper spool keeps more old articles alive. So: as good for modern use, weaker for archive depth.\nDoes backbone choice affect download speed? It can, but speed is dominated by your routing, peering and connection count more than by the backbone label alone. What the backbone really affects is completion — how much of a given release is actually retrievable — which in turn decides whether your PAR2 repair budget can finish the job. A fast connection to a backbone that is missing chunks still fails at the repair stage.\nShould I use both Omicron and UsenetExpress? That is the pro move, and it is usually cheap. Run your main provider on one backbone, then add a block account on the other as a fill server. When your primary cannot complete a download, your client silently retries the missing articles on the second backbone. It is the most reliable way to push completion from roughly 96% to 99% without paying for two full subscriptions.\nWhere to go next Weighing the whole field, not just the two big backbones? Best Usenet Providers UK 2026. Working to a budget? Cheapest Usenet providers costs it out per gigabyte. Want the fill-server tactic, properly explained? Block accounts explained. Download failed at 98%? That is a completion problem — fix it with the PAR2 repair playbook. Making sure a release is worth pulling at all? Usenet indexers explained and retention explained. ","permalink":"https://usenetpirate.co.uk/guides/usenet-omicron-vs-usenetexpress/","summary":"\u003cp\u003eIf you have priced up Usenet providers for more than five minutes, you have noticed the same thing I did: almost every \u0026ldquo;comparison\u0026rdquo; is really a list of \u003cem\u003ebrands\u003c/em\u003e, not \u003cem\u003enetworks\u003c/em\u003e. Eweka, TweakNews, Newshosting, NewsgroupDirect, UsenetExpress, ViperNews — they sound like rivals. Most of them are not. They are shopfronts, and underneath sit a handful of actual storage backbones that do the work. Get the backbone wrong and no amount of brand familiarity saves you; get it right and the rest is just price.\u003c/p\u003e","title":"Omicron vs UsenetExpress: Which Usenet Backbone Wins?"},{"content":"You download a 40 GB release, it hits 97% and stops. The status sits on \u0026ldquo;repairing\u0026rdquo; for ten minutes and then spits out a file that will not extract. If you have used Usenet for more than a week, you have met PAR2 — even if you have never consciously thought about it. This guide is the explainer most Usenet sites never write: what PAR2 recovery files actually are, how a repair works under the hood, why a file fails despite your provider\u0026rsquo;s giant retention number, and the settings in SABnzbd and NZBGet that decide whether a download lands clean or dies at the finish line.\nIf you are new to the whole system, read What is Usenet and how does it work? first — this page assumes you know what an article and an NZB are. If you want the theory behind why repairs are needed at all, that is the retention guide. This page is the practical one: how to fix the download.\nWhat PAR2 Actually Is PAR2 stands for Parity Archive, volume 2. It is an error-correction scheme, not a compression format and not a container. When someone posts a binary to Usenet, the tools that build the release also generate a set of parity (.par2) files and place them alongside the main archives in the same post. Your provider stores those parity files exactly like any other article, and your downloader fetches them as part of the NZB.\nThe idea is the same one behind a RAID array, or a checksum puzzle in a crossword. Instead of storing the file once, the poster stores the file plus a small percentage of extra mathematical \u0026ldquo;checksum\u0026rdquo; data. That extra data is engineered so that any missing piece of the original can be reconstructed from the pieces that did survive. Lose a random 4% of a release, and a 10% parity set rebuilds you a byte-perfect original — no re-download of the missing chunks required.\nTwo numbers matter, and they are related but distinct:\nParity volume — the percentage of extra data the release ships with. Almost always 5–10%. This is your hard repair ceiling. Recovery blocks — the parity data counted as discrete blocks. Each block you have can fix one equivalent block of missing data, up to the total parity. That first number is the one that decides whether you get your file. Remember it: you can only repair as much as the poster shipped.\nPAR2 is a set, not a single file Almost every release comes with a PAR2 set — typically one small index file (like release.par2 or release.vol00+01.par2) and a stack of larger volume files (release.vol01+04.par2, release.vol05+08.par2, and so on). The index tells your downloader which files belong to the set and what to expect; the volume files carry the actual recovery data.\nYou can see this in the NZB before you ever download. Pull any NZB into a text editor and you will find .par2 filenames listed right after the main archives. That presence is what tells SABnzbd and NZBGet that a release is repair-capable at all. If the indexer\u0026rsquo;s NZB omits the parity files, you have no repair headroom — a point I come to in the indexers guide.\nWhat it is not Three quick clarifications that save arguments:\nPAR2 is not RAR. RAR is compression and volume splitting; PAR2 is error correction. A release has both, and they do different jobs: PAR2 puts missing data back, RAR packs it small. A RAR volume that is corrupt is a job for PAR2; PAR2 itself never compresses anything. PAR2 is not a download accelerator. It is not downloaded \u0026ldquo;for speed.\u0026rdquo; It is downloaded so a damaged post can be salvaged. Downloading more parity than you need is pure overhead — which is why the percentage is small. PAR2 is not new. The format dates from 2003 (an improvement on the original PAR), and it has been the standard for binary Usenet ever since. The tools have changed; the maths has not. How Repair Actually Works (the bit most explainers skip) Here is what happens between \u0026ldquo;download finished\u0026rdquo; and \u0026ldquo;extracting\u0026rdquo;:\nDownload. SABnzbd or NZBGet pulls every article listed in the NZB — the archives, plus the smallest PAR2 index file, then only the extra parity blocks it actually needs. Neither client grabs the whole parity set up front. Verify. The downloader reads the PAR2 index, hashes what it received, and compares it against the checksums. It now knows exactly which articles are missing or corrupt, and how many. Decide. If nothing is missing, verification passes and repair is skipped entirely — no CPU cost, straight to extraction. If data is missing, the downloader checks whether the parity set contains at least as many recovery blocks as there are damaged blocks. Repair. If it does, the downloader runs a Reed–Solomon decode — the same family of maths used in CD error correction — reconstructing the missing blocks from the parity. It writes a complete, correct set of archives out. Extract \u0026amp; rename. The now-complete archives are unpacked and renamed into your media folder. Two things about step 4 are worth internalising:\nRepair is all-or-nothing at the block level. The downloader cannot \u0026ldquo;half repair.\u0026rdquo; If you are one recovery block short, the repair fails and you get the same broken file you started with. There is no partial credit. Repair is CPU-bound and I/O-heavy. The Reed–Solomon decode runs across the entire file, not just the missing part, and it hammers both CPU and disk. On a fast line and a beefy box you never notice it. On a low-RAM NAS or a Raspberry Pi, this is exactly where a download that was cruising at full speed stalls — the network is done, the CPU is not. Which is why the SABnzbd vs NZBGet choice matters more than people think once repairs get big. Why a File Fails Despite High Retention This is the confusion that trips up almost everyone, and it is worth slowing down for. You bought a provider with 6,000 days of retention — sixteen years — and a file from two years ago still failed its repair. How?\nBecause retention and completion are two different things, and repair sits on top of both.\nRetention says how long articles are kept. It is a promise about the calendar. Completion says how many of the articles you ask for the provider can actually serve. It is a promise about the reality inside that window. PAR2 is the emergency budget that papers over the gap between the two — but only up to the parity the release shipped with. A provider can truthfully advertise 6,000 days and still hand you a 96%-complete post, because chunks of it were never propagated to their spool, or got taken down after a rights complaint. Here is the sentence to remember, because it is the whole article in one line: PAR2 can only repair the difference between what you got and 100% — and only up to its parity cap (usually 5–10%). If your completion gap is bigger than the release\u0026rsquo;s parity, no repair can save it, no matter how deep the retention.\nThat is exactly why the retention explainer argues completion beats a big retention number, and why a multi-backbone provider is really a second repair budget: when one spool\u0026rsquo;s copy is short a few articles, another backbone\u0026rsquo;s copy is complete, and the download never needs to repair at all.\nThe five ways a download actually breaks If you know the failure mode, you know the fix. In rough order of frequency:\nMissing articles from the spool. The single biggest cause. Articles aged out, were never propagated, or were removed. Shows up as \u0026ldquo;not enough repair blocks\u0026rdquo; when the gap exceeds parity. Takedowns and DMCA removals. A chunk of a popular release gets pulled from one backbone while the rest survives. Another reason the same post can complete on one provider and fail on another. Propagation gaps. With tens of petabytes a day crossing the network, some articles simply do not land on every spool. Random, transient, and exactly what a second backbone covers. A bad or incomplete NZB. If the indexer\u0026rsquo;s NZB mis-points the parity files or carries dead article references, your repair tool is working from a broken map. Quality here is not cosmetic — the indexer guide\u0026rsquo;s PAR2 section is worth reading for this alone. Local failures. Disk errors on the download side, not the Usenet side. If your download lands on a failing drive, the article arrives corrupt and PAR2 sees damage that was never Usenet\u0026rsquo;s fault. Check your disk before you blame your provider. Fixing It: SABnzbd SABnzbd does PAR2 for you. You do not normally invoke a repair command; you make sure it can. The settings that matter:\nPost-processing level. This is a per-job option with a per-category default, set under Config → Categories → Default (choose Repair, or Repair + Unpack + Delete). It is not on the Switches page. This is what tells SABnzbd to verify and repair rather than accept whatever arrived. If you have a download that refused to repair, check this first — it is the usual culprit. Maximum retries (under Server). SABnzbd retries a failed article a set number of times per server. Raising this above the default helps when a spool hiccups on a single article — a surprising share of \u0026ldquo;missing\u0026rdquo; articles are transient and come back on a second pass at zero extra cost. To pull missing articles from a different spool instead, give SABnzbd a second server at a higher priority number and tick Optional (the block-accounts guide covers this). What SABnzbd lacks is NZBGet\u0026rsquo;s retry-after-failure action — not the ability to use a second server. Repair threads. SABnzbd has no dedicated repair-threads field; you set it under Config → Switches → Extra Par2 parameters, which is passed straight to the par2 command line. Use -t — -t1 forces a single thread, and omitting it uses every core. On a low-power box, -t2 is a sensible cap; more threads than cores just makes the machine thrash. Propagation delay. If you grab releases the instant they post and see frequent \u0026ldquo;not enough repair blocks,\u0026rdquo; add a propagation delay (10–30 minutes). You are fetching before the post has finished spreading across backbones; waiting lets the missing articles arrive. When a download is stuck repairing or has failed, the sequence is: pause the queue, make sure your backup server is enabled, and give the release a propagation delay before the next attempt. If it still fails on the same backbone, the post is genuinely short its parity there — that is a job for a second source, not a setting.\nFixing It: NZBGet NZBGet is the lighter, lower-RAM alternative, with its own multithreaded PAR2 verifier and repair engine built into its C++ core — the same job SABnzbd hands to the external par2cmdline, but far gentler on constrained hardware. See the full comparison for the resource trade-offs; here are the repair-specific bits:\nParCheck / ParRepair. Under Settings → CHECK AND REPAIR, make sure ParCheck is set to Auto or Force and ParRepair is on (both are defaults). ParCheck verifies; ParRepair rebuilds. ParThreads. NZBGet exposes a thread count for repair; leave it low (1–2) unless repairs are the bottleneck. ParBuffer and disk. Repair streams through a buffer — if you see heavy disk thrash, give it more room or move the download to faster storage. Secondary server + Retry failed articles. Give NZBGet a second server (a block account) and it can re-request articles your primary could not supply; ArticleRetries sets how many times it retries an article before giving up. That is the mechanism that pairs with a block account — its separate dupe handling is only duplicate detection, not repair. The headline advantage is the same one that makes NZBGet the pick for NAS boxes: its verifier and repair are built into a C++ core and parallelise well, so a repair that would stall a low-spec SABnzbd box just churns through. On a modern desktop, the difference vanishes.\nCan You Repair PAR2 Manually? Yes — and it is occasionally useful, but for a very narrow set of cases.\nQuickPar (Windows) is the classic GUI. Open the .par2 index file, it scans the accompanying files, shows you what is missing, and repairs it with one click. MultiPar is the modern Windows successor with more options and better multi-core use. par2cmdline does it on the command line on Linux/macOS — the very engine SABnzbd shells out to for verification and repair (NZBGet instead uses its own built-in implementation). The catch: manual repair only works if you already have the .par2 files on disk. If you never downloaded the parity set, there is nothing to repair with, and no GUI can invent it. This is why \u0026ldquo;just repair it manually with QuickPar\u0026rdquo; is useless advice for a download that failed because the parity was never fetched — and why it is almost never worth doing in an automated setup. Let the downloader handle it and spend your time fixing the cause (completion, indexer quality, a second backbone) instead of the symptom.\n\u0026ldquo;Not Enough Repair Blocks\u0026rdquo; — the Only Fix That Works Sooner or later you will see the error that ends all hope: \u0026ldquo;repair failed: not enough repair blocks.\u0026rdquo; It is worth being blunt about what it means, because there is a lot of voodoo online about it.\nIt means the download is missing more articles than the parity set can cover. You are past the release\u0026rsquo;s recoverable limit on your provider\u0026rsquo;s copy of that post. No amount of requeuing, thread-tweaking, or \u0026ldquo;repair harder\u0026rdquo; changes that arithmetic — the missing data does not exist on the spool you are pulling from.\nThe genuine fixes, in order:\nAdd a second source on a different backbone. This is the real one. A block account from another backbone gives your downloader somewhere else to pull the missing articles. SABnzbd and NZBGet support a \u0026ldquo;fill\u0026rdquo; or \u0026ldquo;backup\u0026rdquo; server exactly for this: primary provider first, backup picks up what it cannot complete. This is the single most effective PAR2 fix in existence — see how it is set up in the block accounts guide. Pull a different release. If the same content was posted again (a re-post, a different group), its parity set is fresh and the download may repair cleanly. Find a better NZB. If every copy of a release fails, the indexer\u0026rsquo;s NZB may be the problem. The indexer quality angle is real. What is not a fix: buying more retention. The bytes are gone from that spool; a deeper one would not have helped. And this is the practical reason a multi-backbone account like NewsgroupDirect\u0026rsquo;s Grand Slam (NewsgroupDirect + Supernews + Usenet.Farm + ViperNews behind one login) keeps earning its place: coverage across backbones is a repair budget that does not run out at 10%.\nThe UK Angle: Repair, Speed and Fair Use Two UK-specific notes, because they shape how repair feels in practice.\nRepairs want CPU, and cheap UK setups skimp on it. A lot of UK Usenet users run SABnzbd on a NAS or a small home server to keep the download box quiet and low-power. That is a great choice until repairs get big — then a CPU that only had to shuffle bits suddenly has to run a Reed–Solomon decode, and the finish line is where it stalls. If you are on modest hardware and see frequent stalls at 99%, your repair phase is the bottleneck, not your line speed. NZBGet or a faster box is the honest fix. FUP interacts with repeated downloads. If a download fails and you re-pull it, you have paid for that data twice. On a block account that costs you GB; on a UK broadband fair-usage policy it nudges you toward a cap. The lesson is the same either way: fix the cause of failed downloads (completion, a second backbone) rather than re-rolling the dice, and you spend less on wasted transfers. The cheapest providers guide costs this out properly. The Honest Recommendation PAR2 repair is not a feature you shop for — it is a property of almost every release you download, and a good provider simply makes it rare. The purchase that actually reduces your repair failures is a second backbone as a fill server, which is cheap and permanent:\nAlready on an unlimited provider? Add a NewsgroupDirect block account and point it at the fill/backup slot. When a release comes up short on your main spool, the block silently covers the gap and the download completes — often with PAR2 never needing to run at all. 👉 Grab a NewsgroupDirect block account here — a small block is a cheap test; a bigger one becomes the permanent second backbone that makes \u0026ldquo;not enough repair blocks\u0026rdquo; disappear.\nFor the theory underneath all of this — why a 6,000-day spool can still give you a 96% file — read Usenet retention explained. For the downloader whose repair engine you are actually relying on, see SABnzbd vs NZBGet.\nAffiliate disclosure: this page contains affiliate links. If you sign up through them we may earn a commission — at no extra cost to you. It never changes what we recommend; a second backbone on a block is covered here because it genuinely fixes the problem, not because anyone paid for the placement.\nFAQ What are PAR2 files on Usenet? PAR2 (Parity Archive, volume 2) files hold redundant error-correction data posted alongside a release, usually 5–10% of its size. Your downloader uses that parity to mathematically reconstruct any articles that are missing or corrupt, so a slightly incomplete download can still be rebuilt into a perfect file.\nHow do I repair an incomplete Usenet download? You usually don\u0026rsquo;t — your downloader does it automatically. SABnzbd verifies the completed articles against the PAR2 set and runs a repair when it detects missing blocks. If a download is stuck, requeue the NZB and make sure your backup server is enabled so it can re-fetch the missing articles before repairing.\nWhy does PAR2 repair fail? Almost always because the download is missing more articles than the release\u0026rsquo;s parity can cover. PAR2 can only reconstruct up to the redundancy that shipped with the post — typically 5–10%. Lose more than that and no repair can save it, however many times you retry.\nCan I repair PAR2 files manually? Yes, if you have the .par2 set on disk. QuickPar and MultiPar on Windows can repair, and par2cmdline does it on the command line. But there\u0026rsquo;s almost no point — SABnzbd runs the same repair engine automatically, and NZBGet has its own built into its core, so manual PAR2 is only worth it for one-off files pulled outside a downloader.\nWhat does \u0026ldquo;repair failed — not enough repair blocks\u0026rdquo; mean? It means the download is missing more data than the parity set can cover. The release is past its recoverable limit for your provider\u0026rsquo;s copy of the post. The fix is not to repair harder — it\u0026rsquo;s to pull the missing articles from another source, usually a block account on a different backbone.\nDoes PAR2 repair need more CPU or RAM? Yes. Repair is a Reed–Solomon decode across the whole file — CPU-bound and I/O-heavy. On a low-RAM NAS or a Raspberry Pi, repair is exactly where a fast download stalls at the finish line. If that\u0026rsquo;s your setup, NZBGet handles the decode more lightly than SABnzbd.\nWhere to Go Next New to Usenet entirely? Start with What is Usenet and how does it work?. Why repairs happen at all — and why retention lies: Usenet retention explained. Add the second backbone that kills failed repairs: Usenet block accounts explained. Pick the downloader whose repair engine fits your hardware: SABnzbd vs NZBGet. Fix the source of bad NZBs: Usenet indexers explained. Setting up from zero? Follow the 2026 setup guide. Choosing a provider that repairs rarely in the first place? Best Usenet Providers UK 2026. Weighing Usenet against torrents, where a dead swarm can\u0026rsquo;t be repaired at all? Usenet vs torrents. ","permalink":"https://usenetpirate.co.uk/guides/par2-repair-usenet/","summary":"\u003cp\u003eYou download a 40 GB release, it hits 97% and stops. The status sits on \u0026ldquo;repairing\u0026rdquo; for ten minutes and then spits out a file that will not extract. If you have used Usenet for more than a week, you have met PAR2 — even if you have never consciously thought about it. This guide is the explainer most Usenet sites never write: what PAR2 recovery files actually are, how a repair works under the hood, why a file fails \u003cem\u003edespite\u003c/em\u003e your provider\u0026rsquo;s giant retention number, and the settings in SABnzbd and NZBGet that decide whether a download lands clean or dies at the finish line.\u003c/p\u003e","title":"PAR2 Repair on Usenet: How to Fix Incomplete Downloads"},{"content":"Every Usenet guide on the internet tells you the same thing: buy an unlimited subscription, it\u0026rsquo;s the only sane choice. And for a heavy user, that\u0026rsquo;s true. But \u0026ldquo;unlimited or bust\u0026rdquo; is a lie the affiliate sites keep telling because subscriptions pay them more.\nThe truth is duller and more useful: a block account is the right answer for a huge number of people, and for everyone else it\u0026rsquo;s the best second purchase they\u0026rsquo;ll ever make. If you download casually, if you want to test a backbone before committing, or if you\u0026rsquo;re chasing the last few percent of completion on a stubborn download, a block is not the budget option — it\u0026rsquo;s the correct option.\nThis guide explains exactly what block accounts are, how the pricing actually works, when they win, when they lose, and the fill-server trick that turns a £10 block into a meaningful upgrade on your main provider.\nAffiliate disclosure: this page contains affiliate links. If you sign up through them we may earn a commission — at no extra cost to you. It never changes what we recommend or how we rank providers; block accounts are covered here because they suit a lot of people, not because anyone paid for the placement.\nWhat is a Usenet block account? A block account is a prepaid bundle of download allowance — typically sold as a fixed number of gigabytes — that you buy once and draw down as you use it. There\u0026rsquo;s no monthly bill and, on every serious provider, the unused data never expires. Buy 100 GB today, use 8 GB this month and let it sit untouched for six months; the remaining 92 GB is still there when you come back.\nThat\u0026rsquo;s the whole model. No commitment, no recurring charge, no cancellation dance. You are buying a quantity of data, not a period of access.\nSubscriptions work the opposite way. You pay per month (or per year) for unlimited use, and if you don\u0026rsquo;t use it, you\u0026rsquo;ve simply wasted that month. Blocks are pay-as-you-go; subscriptions are pay-as-you-exist.\nBlocks vs subscriptions at a glance Block account Unlimited subscription Pricing model Per GB, prepaid Per month/year, flat Expiry Never (reputable providers) Month/period rolls over Commitment None Renewing Best for Casual use, fill servers, testing Heavy use, automation, large libraries Cost behaviour Scales with actual usage Flat regardless of usage Typical entry cost £5–£20 £5–£12/month Neither is \u0026ldquo;better\u0026rdquo;. They\u0026rsquo;re tools for different jobs, and the mistake most people make is buying the wrong one for their usage — usually paying for unlimited they don\u0026rsquo;t touch, or getting stung mid-download by a block that ran dry.\nHow block consumption actually works Every article downloaded from Usenet is made of articles — small pieces of a file, each stored across multiple servers. When your newsreader (SABnzbd, NZBGet, and so on) fetches a file, it downloads those articles and counts them against your allowance.\nA few things matter here:\nYou pay for what you fetch, not what you keep. Redownloading the same file costs you again. PAR2 repair blocks — the recovery data that fixes incomplete downloads — are also downloaded and also counted. That\u0026rsquo;s why a badly-retained file can \u0026ldquo;cost\u0026rdquo; more than its stated size: you\u0026rsquo;re paying for the repair work too. What counts varies by provider. Most charge for data actually transferred, but some setups can count a partly-fetched or retried article. The practical upshot is the same: downloads that repeatedly stall and re-try on a poorly-covered backbone cost you more than a clean one — another reason a second backbone as a fill server pays off. Only downloads count. Browsing, searching, and indexer queries don\u0026rsquo;t touch your block. It\u0026rsquo;s purely about data pulled from the provider\u0026rsquo;s servers. If you want the deeper mechanics, our retention explained piece covers how articles age and why older posts behave differently.\nThe honest decision: block or unlimited? Forget the marketing. Answer these three questions honestly and the decision makes itself.\n1. How much do you actually download per month?\nUnder ~10 GB/month → a block wins, easily. You\u0026rsquo;d need to download for years to justify unlimited at the same money. 10–50 GB/month → it\u0026rsquo;s close. A block is still often cheaper, but you\u0026rsquo;ll want to keep an eye on your balance. Over ~100 GB/month → unlimited wins. At scale, the flat price is unbeatable, and you stop thinking about your allowance entirely. 2. Do you automate?\nIf you run Sonarr/Radarr + SABnzbd and grab everything as it airs, you\u0026rsquo;re a heavy user by definition — even if it doesn\u0026rsquo;t feel like it. Automation downloads a lot, quietly. Get unlimited.\n3. Are you chasing completion, or just convenience?\nIf you want a specific hard-to-find file to finish, a block on a second backbone is the pro move (see the fill-server section below). If you just want \u0026ldquo;whatever\u0026rsquo;s new\u0026rdquo; to land reliably, unlimited plus a good indexer is simpler.\nThe maths nobody shows you Say you download 8 GB a month of actual content. That\u0026rsquo;s 96 GB a year before overhead — and Usenet always carries overhead. PAR2 recovery data and retries typically add 5–10%, so budget roughly 100–105 GB of block for 96 GB of content. A 100 GB block is therefore about a year at this rate, not comfortably more.\nAn unlimited plan at £6/month = £72/year. A 100 GB block for ~£15 (typical mid-range price) = £15, covering you for roughly a year at that rate. That\u0026rsquo;s not a marginal saving — it\u0026rsquo;s roughly 80% cheaper for comparable usage (before overhead). The affiliate sites won\u0026rsquo;t tell you that because a block pays them once and a subscription pays them forever. The exception: if one month you binge 400 GB, the block runs dry mid-download and you\u0026rsquo;re stuck. Blocks reward predictable, modest usage; subscriptions reward volume and carelessness.\nWhen a block account is the right call Casual downloading. You grab a handful of files a month. Unlimited is a subscription to something you barely use.\nTesting a provider or backbone. Want to know whether a backbone performs well on your line before committing to a monthly plan? Buy a small block, hammer it, and judge for yourself. If it\u0026rsquo;s good, upgrade to unlimited with confidence. If it\u0026rsquo;s not, you\u0026rsquo;ve spent pocket change, not signed a contract.\nOverage protection on top of unlimited. Some \u0026ldquo;unlimited\u0026rdquo; plans have fair-use limits or throttle after a soft cap. A block from a different provider is your overflow valve.\nFill / backup server. This is the big one, and it gets its own section.\nEveryday, non-automated users. If you don\u0026rsquo;t have a download stack running 24/7, a block matches how you actually use Usenet: in bursts, when you want something.\nThe fill-server trick (the reason pros buy blocks) Here\u0026rsquo;s the thing the \u0026ldquo;just get unlimited\u0026rdquo; crowd misses: no single provider has 100% of everything, everywhere. Each provider sits on a backbone (Omicron, UsenetExpress, Abavia and so on — compared head to head in the Omicron vs UsenetExpress guide), and backbones differ in what they store and for how long. A file that\u0026rsquo;s missing on Omicron might be complete on UsenetExpress, and vice versa.\nA fill server (sometimes \u0026ldquo;backup server\u0026rdquo;) is a second provider, usually bought as a block, added behind your main account in SABnzbd/NZBGet. Your downloader tries your primary provider first; anything it can\u0026rsquo;t complete, it quietly retries against the fill server on the other backbone. The download finishes instead of failing.\nThis is why the most experienced users run unlimited on one backbone + a block on another. The block isn\u0026rsquo;t their daily driver — it\u0026rsquo;s insurance that every download completes. It\u0026rsquo;s often the difference between a 96% completion rate and a 99% one, and that last few percent is exactly where stubborn, old, or niche files live.\nFor a stack that leans on automation, a fill block is genuinely the highest-value £10–£15 you can spend. Our SABnzbd vs NZBGet guide shows where the fill-server settings live.\nWhen unlimited wins (don\u0026rsquo;t kid yourself) Be honest about these, because a block here will just frustrate you:\nHeavy, sustained downloading. Multiple hundreds of GB a month. Flat pricing is made for you. Full automation. Sonarr/Radarr running all day. You\u0026rsquo;ll blow through any block and hate the admin. Large libraries and remuxes. 4K remuxes alone are 40–80 GB per film. A 100 GB block is two downloads. You want to stop thinking about it. The honest appeal of unlimited isn\u0026rsquo;t speed — it\u0026rsquo;s not having a counter in your head. If any of those describe you, buy unlimited and add a cheap block from another backbone as a fill server. Best of both.\nHow to buy a block without getting ripped off Not all blocks are equal. Judge them on these, in order:\nBackbone, not brand. Two providers with different names may sit on the same backbone — a fill server on the same backbone fills nothing. Check which backbone you\u0026rsquo;re buying before you pay — the provider\u0026rsquo;s own site usually states it, and our cheapest providers table lists each provider\u0026rsquo;s backbone side by side. Price per GB. Divide price by size. Good blocks land in roughly the $0.04–$0.12/GB range for the best-value providers (see our cheapest providers table), rising with smaller sizes and premium backbones. You\u0026rsquo;re usually better off buying a bigger block (lower $/GB) than several small ones — as long as it doesn\u0026rsquo;t expire. Expiry. Reputable providers: never. If a block \u0026ldquo;expires\u0026rdquo; after 30–90 days, you\u0026rsquo;re not buying a block, you\u0026rsquo;re buying a disguised subscription with worse terms. Walk away. Retention. The stored-file window. For a fill server especially, you want at least matching retention to your main provider, ideally more. A cheap block with poor retention will fail exactly the old files you bought it to rescue. Connections. Enough simultaneous connections to actually use your line (20+ is standard; more is better on gigabit). Payment and reputation. Stay with established providers. Blocks are prepaid — you want someone who\u0026rsquo;ll still exist next year. A note on price signals If a block is dramatically cheaper than everyone else, ask why before celebrating. Common reasons: terrible retention, a shaky/short-lived backbone, connection caps so low the block is unusable at speed, or expiry hidden in the small print. Cheap is fine; cheap and clear about its limits is better.\nThe honest recommendation For UK users who download casually, want to keep a second backbone as a fill server, or simply want to test before they commit, a block account is the sensible buy — and NewsgroupDirect is the one this site actually uses and recommends for it. Their blocks are prepaid, don\u0026rsquo;t expire, sit on solid retention, and the per-GB pricing is competitive without hiding the limits. Importantly, NGD sits on the UsenetExpress backbone — a genuinely different backbone from the Omicron-based providers most people run as their main subscription, which is exactly what you want from a fill server. It\u0026rsquo;s the provider we point to because it earns it.\n👉 Grab a NewsgroupDirect block account here — small block to test, or a bigger one as a permanent fill server.\nIf you\u0026rsquo;re a heavy or automated user, get unlimited on your main provider and add a small NGD block as the fill server behind it. That combination — unlimited on one backbone, block on another — is what most serious setups actually run.\nCommon mistakes to avoid Buying a block on the same backbone as your main account. It fills nothing. Check the backbone first. Buying the smallest block to \u0026ldquo;save money\u0026rdquo;. You\u0026rsquo;ll run dry mid-download, and per-GB rates are worse. Buy the size that matches your year. Ignoring retention. A fill block with short retention can\u0026rsquo;t rescue old posts — the whole point. Forgetting PAR2 counts. Budget ~5–10% extra for recovery data so a full download doesn\u0026rsquo;t strand you at 99%. Letting a block sit while your main provider is fine. Great — that\u0026rsquo;s the point. It costs nothing to hold; it\u0026rsquo;s insurance, not a subscription. FAQ Do block accounts expire? On reputable providers, no. The data you buy is yours until you use it. If a provider attaches an expiry date, that\u0026rsquo;s a red flag — treat it as a subscription in disguise.\nCan I use a block and a subscription at once? Yes, and you should if you\u0026rsquo;re chasing completion. Set the subscription as your primary server and the block as the fill/backup server on a different backbone.\nIs a block slower than unlimited? Not inherently — speed comes from connections, routing, and backbone, not from how you pay. Some providers give subscribers priority, so check before assuming a block is as fast at peak times.\nWhat happens when a block runs out? Downloads fail until you top up (some providers auto-offer a refill). If you find yourself refilling often, you\u0026rsquo;re a subscription user wearing a block\u0026rsquo;s clothes — switch.\nAre blocks good for a fill server specifically? They\u0026rsquo;re the ideal fill server: low commitment, no expiry, and you only spend when the main provider can\u0026rsquo;t complete.\nWhere to go next New to Usenet entirely? Start with What is Usenet?. Setting up for the first time? How to get started with Usenet in 2026. Comparing providers for the UK? Best Usenet Providers UK 2026. Working to a budget? Cheapest Usenet providers. Understanding retention and PAR2 before you buy? Usenet retention explained. Block accounts aren\u0026rsquo;t the cheap option. They\u0026rsquo;re the honest one — for the right user.\n","permalink":"https://usenetpirate.co.uk/guides/usenet-block-accounts-explained/","summary":"\u003cp\u003eEvery Usenet guide on the internet tells you the same thing: buy an unlimited subscription, it\u0026rsquo;s the only sane choice. And for a heavy user, that\u0026rsquo;s true. But \u0026ldquo;unlimited or bust\u0026rdquo; is a lie the affiliate sites keep telling because subscriptions pay them more.\u003c/p\u003e\n\u003cp\u003eThe truth is duller and more useful: \u003cstrong\u003ea block account is the right answer for a huge number of people\u003c/strong\u003e, and for everyone else it\u0026rsquo;s the best \u003cem\u003esecond\u003c/em\u003e purchase they\u0026rsquo;ll ever make. If you download casually, if you want to test a backbone before committing, or if you\u0026rsquo;re chasing the last few percent of completion on a stubborn download, a block is not the budget option — it\u0026rsquo;s the \u003cem\u003ecorrect\u003c/em\u003e option.\u003c/p\u003e","title":"Usenet Block Accounts Explained: Per-GB Beats Unlimited"},{"content":"The Secret in the Basement While everyone else is fighting over the latest consumer cards with 16GB of VRAM and software-locked features, there\u0026rsquo;s a graveyard of enterprise-grade power sitting in data centres. The AMD Radeon Instinct MI50.\nIt\u0026rsquo;s a gfx906 beast. It\u0026rsquo;s old enough to be \u0026ldquo;cheap\u0026rdquo; on the secondary market, but powerful enough to run models that would make a 3090 look like a calculator — at least for token crunching, where memory bandwidth is king. On raw compute and modern tricks, the 3090 still wins. This build isn\u0026rsquo;t fast; it\u0026rsquo;s capable.\nThe Goal: 64GB Capacity Across Dual Cards By pairing two MI50s, we\u0026rsquo;re creating a 64GB VRAM footprint. We aren\u0026rsquo;t talking unified pools or Infinity Fabric — we\u0026rsquo;re talking high-bandwidth tensor splitting. In the world of local LLMs, VRAM is the only metric that actually matters. 64GB is the \u0026ldquo;sweet spot\u0026rdquo; where you can run Llama 3 70B at Q4/Q5 quantisations with significant headroom for context.\nThe Software Reality (The \u0026ldquo;Gotchas\u0026rdquo;) This is where the \u0026ldquo;enthusiast\u0026rdquo; builds often fail:\nROCm Status: Official ROCm 7.x has dropped gfx906 support. To make this work, you\u0026rsquo;ll be relying on community-maintained forks and specific Docker images (like the mixa3607/ML-gfx906 builds). The BF16 Gap: Vega 20 has no hardware support for bfloat16. While llama.cpp handles this gracefully, some vLLM/Triton workflows will be rough. The Path: llama.cpp is your primary friend here. It\u0026rsquo;s the smoothest way to bridge the gap between legacy hardware and modern weights. The Build Specs (The \u0026ldquo;Don\u0026rsquo;t Brick Your House\u0026rdquo; List) The Cards: Dual AMD Instinct MI50 (target: ~£150 each, eBay UK, used). The Board: A dedicated x8/x8 PCIe split board. Critical: you must ensure \u0026ldquo;Above-4G-Decoding\u0026rdquo; is enabled in your BIOS, or the cards won\u0026rsquo;t even enumerate. The Power: A minimum 1200W Tier-A PSU. These things pull ~300W each under load. You aren\u0026rsquo;t just building a PC; you\u0026rsquo;re building a space heater that happens to do math. The Cooling: Active ducting is non-negotiable. These are passively cooled enterprise cards. If you don\u0026rsquo;t move the air, they\u0026rsquo;ll throttle or cook within 120 seconds of a heavy inference pass. The Verdict It\u0026rsquo;s not \u0026ldquo;easy.\u0026rdquo; You have to deal with community-forked drivers and serious thermal management. But for a few hundred quid, you get a workstation that puts most \u0026ldquo;high-end\u0026rdquo; consumer setups to shame on capacity alone.\nThis is the start of the build log. Next up: the PCIe board selection deep dive and the ROCm fork setup — with the actual numbers once the box is running.\n","permalink":"https://usenetpirate.co.uk/guides/mi50-64gb-vram-build/","summary":"\u003ch2 id=\"the-secret-in-the-basement\"\u003eThe Secret in the Basement\u003c/h2\u003e\n\u003cp\u003eWhile everyone else is fighting over the latest consumer cards with 16GB of VRAM and software-locked features, there\u0026rsquo;s a graveyard of enterprise-grade power sitting in data centres. The AMD Radeon Instinct MI50.\u003c/p\u003e\n\u003cp\u003eIt\u0026rsquo;s a gfx906 beast. It\u0026rsquo;s old enough to be \u0026ldquo;cheap\u0026rdquo; on the secondary market, but powerful enough to run models that would make a 3090 look like a calculator — at least for token crunching, where memory bandwidth is king. On raw compute and modern tricks, the 3090 still wins. This build isn\u0026rsquo;t fast; it\u0026rsquo;s \u003cstrong\u003ecapable.\u003c/strong\u003e\u003c/p\u003e","title":"The MI50 Build: 64GB VRAM for the Price of a Single GPU"},{"content":"The UK market gets flooded every year with \u0026ldquo;best Usenet provider\u0026rdquo; lists that are really disguised sales pages. Every provider on the page is \u0026ldquo;the best\u0026rdquo; because they all paid to be there. That\u0026rsquo;s exactly the kind of nonsense this site was built to cut through.\nSo here it is: the honest, no-BS rundown of the best Usenet providers for UK users in 2026. I\u0026rsquo;ve actually run these accounts, hit the retention limits, watched the completion figures drop, and rebuilt the NZB indexes when things broke. No affiliation shilling — which is exactly why I recommend NewsgroupDirect below where it genuinely earns it.\nAnd because this is a deep dive, I\u0026rsquo;m going past the top-pick summary into the structural questions most roundups dodge: Omicron vs UsenetExpress vs resellers/white-label, and Abavia vs Usenet.Farm specifically. If you understand those, no provider can ever talk you out of your money again.\nWhat Actually Matters for a UK Usenet User Before any names, you need to understand what separates a good provider from a waste of money. Skip this and you\u0026rsquo;ll buy on marketing, not merit.\nBackbone, not brand Almost every Usenet provider just resells another company\u0026rsquo;s backbone. There are really only three storage networks that matter in 2026:\nOmicron (Eweka, TweakNews, Newshosting, and dozens of resellers) — the biggest spool with the deepest binary retention. UsenetExpress (UsenetExpress, NewsgroupDirect, ViperNews, and resellers) — fast, modern, excellent completion on a single coherent spool. Abavia (Usenet.Farm, and a handful of resellers) — the classic independent European backbone. Pick the backbone first, then shop the resellers on price and features. The brand name on the website means almost nothing — the underlying spool is what you\u0026rsquo;re actually paying for.\nRetention Retention is how many days back a provider keeps articles before they\u0026rsquo;re deleted. In 2026 the top tier sits around 5,800+ days (roughly 16 years). Bigger number isn\u0026rsquo;t automatically better — see my Usenet retention explained1 guide for the full picture — but for everyday UK use you want a provider doing at least 4,000 days.\nCompletion Retention tells you how long articles are kept. Completion tells you how complete the binary is when you pull it. This is arguably more important. A provider can tout 6,000 days of retention but return a 98% file that\u0026rsquo;s missing the final chunk. Completion is where cheaper spools quietly fall apart on older, less popular posts — and where your PAR2 repair budget (usually capped at 5–10% of each release) can\u0026rsquo;t save you — at which point the fix is a second backbone, covered in fixing an incomplete download.\nSSL/TLS encryption and UK ISP behaviour If your provider doesn\u0026rsquo;t support SSL on port 563, walk away. In the UK, ISPs have historically throttled Usenet traffic, and unencrypted connections are both slower and visible. Every provider on this list supports TLS. Use it — see the Usenet vs torrents UK ISP section for why SSL on port 563 is the single best defence against UK traffic shaping.\nConnections and speed Most UK broadband lines now do 500 Mbit/s to 1 Gbit/s. Your provider needs to allow enough simultaneous connections (50–100) for a multi-threaded newsreader like SABnzbd or NZBGet to saturate your line. If a provider caps you at 5 connections at 1 Gbit/s, you\u0026rsquo;ll never see fibre speeds. And for the large-transfer stability that heavy UK users need, the connection ceiling matters as much as the headline speed — see the SABnzbd vs NZBGet guide for why.\nThe Contenders Compared I\u0026rsquo;m limiting this to providers with genuinely independent backbones or genuinely differentiated products. A dozen resellers of the same Omicron spool are one product with different logos.\nProvider Backbone Retention Connections Price (unlimited) Standout NewsgroupDirect NGD + Supernews + Usenet.Farm (Abavia) + ViperNews (UsenetExpress) Up to 5,861 days 100 ~$9/mo, ~$75/yr 4 backbones, one account Eweka Omicron (NL) ~15 years (deep) 20 low double-digit GBP Biggest deepest spool Newshosting Omicron ~11 years 60 ~$99/yr Omicron without the setup fuss UsenetExpress UsenetExpress ~5,000 days 100 ~$8/mo tiered Fast, clean, cheap Usenet.Farm Abavia (NL) 3,000+ days 20 ~£6/mo tiered Cheap block deals Prices roughly reflect 2026 unlimited plans as published at the time of writing. Exactly what you pay depends on promo pricing and billing cycle — check the vendor before committing.\nDeep Dive One: Omicron vs UsenetExpress (and where resellers fit) This is the structural question that explains half the market. Let me break it down cleanly — and there\u0026rsquo;s a full head-to-head in the dedicated Omicron vs UsenetExpress deep dive if you want the standalone version.\nOmicron: the deep spool giant Omicron (often grouped with the \u0026ldquo;Abavia\u0026rdquo; confusion, but it\u0026rsquo;s a separate, much larger network) is the 800-pound gorilla. Eweka, Newshosting, TweakNews, and a huge list of resellers all resell Omicron storage.\nStrength: depth and breadth. Omicron ingests the lion\u0026rsquo;s share of the global feed, so it completes best across common content and reaches deepest into old archives. If you pull ten-year-old binaries, Omicron is where they live. Weakness: consistency. Because so many resellers sit on the same spool, everyone on Omicron shares its gaps. Big-name takedowns on Omicron hit every Omicron reseller at once — there\u0026rsquo;s no independent spool to catch it. And several Omicron front-ends cap connections low (Eweka at ~20), which hurts you on gigabit fibre. UsenetExpress: the fast modern completion play UsenetExpress is a newer, independently-built backbone. NewsgroupDirect and ViperNews (both owned by the same company as UsenetExpress) run on it.\nStrength: speed and modern infrastructure. Built for high connection counts (100) and excellent completion on recent and newer content. It keeps up with new releases extremely well and is superb for automation that grabs things the moment they post. Weakness: shallower retention than Omicron (around the 5,000-day mark) and less depth on truly ancient archives. The reseller/white-label trap This is where you lose money if you\u0026rsquo;re not careful. A reseller is just a front-end slapped on someone else\u0026rsquo;s spool. The moment you understand that, a huge chunk of the market becomes obviously samey:\nOmicron white-label resellers (there are dozens, all charging different prices for the identical spool) are one product with different logos and pricing. Buy from the source (Newshosting or Eweka) — a middleman reseller is just Omicron at a markup. UsenetExpress white-label resellers similarly resell the same backbone; buy from the source unless a reseller bundles something genuinely different. The exception that proves the rule: a multi-backbone account — like NewsgroupDirect\u0026rsquo;s Grand Slam (NewsgroupDirect + Supernews + Usenet.Farm + ViperNews) — is not a plain white-label. It\u0026rsquo;s genuinely one login across multiple independents, which is a real product, not a logo swap. The rule: ask \u0026ldquo;which backbone is this?\u0026rdquo; If the answer is a single spool you can get from the source, buy from the source. If the answer is \u0026ldquo;several independent backbones,\u0026rdquo; that\u0026rsquo;s a differentiated product worth paying for.\nVerdict Want old content depth → Omicron (Eweka for the deepest, Newshosting for the friendliest front-end). Want speed and completion on new releases → UsenetExpress. Want both without juggling accounts → a multi-backbone account (NewsgroupDirect Grand Slam). Deep Dive Two: Abavia vs Usenet.Farm Now the confusion that trips up a lot of UK buyers. Usenet.Farm is a brand; Abavia is the backbone it runs on. They\u0026rsquo;re frequently treated as the same thing, and that\u0026rsquo;s mostly fair — but the distinction matters when you\u0026rsquo;re comparing resellers.\nAbavia is the underlying storage network — an independent Dutch backbone with strong European peering and solid completion on newer content. It\u0026rsquo;s resold by Usenet.Farm and a handful of other small providers. Usenet.Farm is the best-known front-end on Abavia, famous for cheap block accounts that never expire and good European performance. For UK users, its Dutch peering tends to mean fast, consistent downloads across European routes. The honest comparison within the independent scene:\nAbavia/Usenet.Farm beats Omicron-reseller-front-ends on price per gigabyte for blocks and on European peering/speed for UK fibre users. Its retention (~3,000+ days) is shallower than the Omicron tier, so it\u0026rsquo;s not the pick if you want decade-old archives. Usenet.Farm vs UsenetExpress: Farm is the budget/block king with European reach; UsenetExpress is the faster, higher-connection-count workhorse. Each is better in different scenarios — Farm for cheap never-expiring blocks and European speed; UsenetExpress for heavy 100-connection limited-data plans. Where it gets smart for UK users: Grand Slam bundles Usenet.Farm\u0026rsquo;s Abavia backbone alongside NGD and UsenetExpress-backed ViperNews. So you get Abavia\u0026rsquo;s European peering and UsenetExpress\u0026rsquo;s speed and deep retention coverage — three genuinely different networks behind one login. That\u0026rsquo;s why it keeps showing up at the top of my recommendations.\nOur Top Pick: NewsgroupDirect (Grand Slam) For most UK users in 2026, NewsgroupDirect\u0026rsquo;s Grand Slam package is the best single purchase — and it\u0026rsquo;s not close.\nHere\u0026rsquo;s why it wins on merit, not because they pay me (they do pay affiliate commission, disclosed below, but only because I\u0026rsquo;d recommend them anyway):\nOne account, four backbones The Grand Slam bundles four genuinely different backbones — NewsgroupDirect\u0026rsquo;s own, Supernews, Usenet.Farm (Abavia), and ViperNews (UsenetExpress) — into a single subscription. That\u0026rsquo;s Omicron-style depth, Abavia\u0026rsquo;s European reach, and UsenetExpress\u0026rsquo;s completion speed behind one login.\nWhy that matters: no single backbone catches everything. Posts that miss on one spool (a takedown on Omicron, say, or a missing article on UsenetExpress) often still land on another. A multi-backbone provider is effectively your own built-in completion failover — and your own redundant PAR2 budget, since missing articles on one spool are covered by a complete read from another. You\u0026rsquo;d normally need three separate accounts to get this; Grand Slam gives it to you as one.\nCoverage when it matters Retention up to ~5,861 days — matches the top of the market. 100 simultaneous connections — enough to saturate gigabit fibre in the UK and keep big transfers stable. SSL on all ports, free headers, and header compression. $13/mo unlimited (Triple Play) or a discounted annual unlimited plan — reasonable, not premium-bloated. Block accounts that never expire — these are also excellent value if you\u0026rsquo;re a light user. For UK users on fibre who want a single account that covers every base without juggling three providers, Grand Slam is the pragmatic answer. → See NewsgroupDirect\u0026rsquo;s current deals2\nBest Omicron Pick: Eweka (for deep, old retention) If your use case is pulling very old binaries — archives from a decade or more ago — Eweka deserves its reputation. It runs on Omicron\u0026rsquo;s own deep dutch spool with retention that stretches back like no one else commercially offers.\nThe catch: Eweka\u0026rsquo;s connection cap (around 20) is low by 2026 standards, and it\u0026rsquo;s pricier than the value plays. If you need ancient content, completion on old posts, and you\u0026rsquo;re not desperate to saturate 1 Gbit/s, Eweka is the right Omicron choice. If you mostly want new releases at fibre speeds, Grand Slam gives you more value.\nMost Honest Value Pick: UsenetExpress / Usenet.Farm blocks For light and budget users, nobody should be paying for a monthly unlimited account. Buy a block — a fixed amount of data that never expires — and only refill when it\u0026rsquo;s gone.\nUsenetExpress sells fast, modern block accounts on its own backbone with strong completion. Usenet.Farm (Abavia, Netherlands) has historically had excellent cheap blocks and good completion, especially for European peers thanks to peering — a real UK advantage. See my cheapest Usenet providers guide for the fully costed comparison of block vs unlimited.\nLarge-Transfer Stability: Who Handles Real UK Fibre Usage Heavy UK users pull hundreds of gigabytes a week. Across all of these, the combination that matters for sustained full-line speed is: high connection allowance + good European routing/peering + strong completion so PAR2 repairs are rare. In practice:\nNewsgroupDirect (Grand Slam): 100 connections + multi-backbone. The best large-transfer stability, because a gap on one spool is caught by another before it becomes a stalled download. UsenetExpress: 100 connections, modern infrastructure. Excellent sustained throughput on new content. Newshosting: 60 connections, Omicron depth. Solid, but the middle connection count limits gigabit saturation. Eweka: 20 connections — fine for moderate use, but it will not saturate a gigabit line. Usenet.Farm: 20 connections unlimited, but superb cheap blocks. Great for light/moderate European-heavy use. For the downloader side of stability — repair CPU, RAM, connection handling — see SABnzbd vs NZBGet.\nThe Providers I\u0026rsquo;d Skip Free Usenet providers. There\u0026rsquo;s no such thing as genuinely good free Usenet in 2026. Free tiers mean tiny retention, crippled speeds, aggressive data caps, or selling your email address. Pay a few quid a month or buy a block. Omicron whitelabel resellers at premium prices. If the website is an Omicron reseller charging more than Newshosting or Eweka directly, you\u0026rsquo;re paying a middleman for the same spool. Buy from the source. Single-backbone white-label resellers in general. Remember the reseller rule: same spool, different logo, markup. There\u0026rsquo;s almost no reason to pay a reseller for a backbone you can buy direct. Providers without standalone SSL/port-563. Non-negotiable for UK users. Affiliate Disclosure This page contains affiliate links. If you buy a provider through one, UsenetPirate earns a small commission at no extra cost to you. That\u0026rsquo;s it — it does not change a single recommendation here. I only link providers I\u0026rsquo;d genuinely recommend, and I\u0026rsquo;ve deliberately not stuffed affiliate links everywhere. Rankings are based on actual use and published specs, not who\u0026rsquo;s paying.\nNext Steps New to Usenet? Read What is Usenet and how does it work first — the short plain-English version. Understand retention and PAR2 before you pay for it: Usenet retention explained. Ready to set up? Follow the 2026 setup guide. Wondering whether Usenet beats torrents, with the UK ISP angle? Usenet vs torrents. On a budget? The cheapest Usenet providers roundup costs it out. Read the full definition of retention before you overpay for a number you don\u0026rsquo;t need.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nAffiliate link: if you buy through this, UsenetPirate may earn a commission at no extra cost to you. It doesn\u0026rsquo;t change the recommendation — I\u0026rsquo;d pick Grand Slam regardless.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://usenetpirate.co.uk/providers/best-usenet-providers-uk/","summary":"\u003cp\u003eThe UK market gets flooded every year with \u0026ldquo;best Usenet provider\u0026rdquo; lists that are really disguised sales pages. Every provider on the page is \u0026ldquo;the best\u0026rdquo; because they all paid to be there. That\u0026rsquo;s exactly the kind of nonsense this site was built to cut through.\u003c/p\u003e\n\u003cp\u003eSo here it is: the honest, no-BS rundown of the best Usenet providers for UK users in 2026. I\u0026rsquo;ve actually run these accounts, hit the retention limits, watched the completion figures drop, and rebuilt the NZB indexes when things broke. No affiliation shilling — which is exactly why I recommend \u003cstrong\u003eNewsgroupDirect\u003c/strong\u003e below where it genuinely earns it.\u003c/p\u003e","title":"Best Usenet Providers UK 2026: Independent, Honest Comparison"},{"content":"\u0026ldquo;Cheapest Usenet provider\u0026rdquo; is a trap. Every budget roundup on the internet quotes the headline monthly price and stops there, ignoring the data caps, the connection limits, and the fact that you might be paying for a whole unlimited account when a £3 block would cover six months of your actual use.\nSo let\u0026rsquo;s cost this out properly. Not the marketing price — the real cost for how you actually use Usenet — and add the one thing budget lists almost always miss: which backbone you\u0026rsquo;re on, because that silently changes both what \u0026ldquo;cheap\u0026rdquo; gets you and how much usable speed you actually see.\nThe One Decision That Saves Most People Money Before you compare providers, decide: block vs unlimited.\nA block account is a fixed amount of data (say 100 GB or 1 TB) that never expires. Pay once, use it until it\u0026rsquo;s gone, refill when you need to. An unlimited account is a monthly subscription for as much data as you care to pull. Here\u0026rsquo;s the unfashionable truth: for most casual-to-moderate UK users, a block is dramatically cheaper than even the cheapest unlimited plan. Set up automation and a lot of people burn through most of what they\u0026rsquo;d ever download in a month or two, then an unlimited subscription just keeps billing them forever.\nThe Backbone Question Cheap Lists Ignore Before the prices, remember the backbone rule from the UK roundup: almost every front-end resells Omicron, UsenetExpress, or Abavia storage. \u0026ldquo;Cheap\u0026rdquo; on a reseller of a backbone you could buy direct is usually worse value than \u0026ldquo;cheap\u0026rdquo; on the source or on a genuinely multi-backbone account. Two angles skew real cost:\nWhite-label markup. A no-name reseller flogging Omicron for £4/mo when Newshosting sells the same spool for similar or less is just a middleman fee. Cheap on paper, worse actual value. Connection caps on cheap plans. The cheapest unlimited plan often has the fewest connections. A £4/mo \u0026ldquo;cheap\u0026rdquo; plan that gives you 10 connections will not saturate a UK gigabit line — so it\u0026rsquo;s cheap per month but slow per byte, which matters once you\u0026rsquo;re moving data at scale. In short: the truly cheapest option is a block from a source backbone (or a multi-backbone bundle) — not the loudest discount banner. Which backbone you pick is a whole decision of its own — see the Omicron vs UsenetExpress comparison.\nCheapest Options, Costed Honestly (2026) Rough published prices from the time of writing. Always double-check the vendor — promo pricing shifts constantly.\nCheap Blocks (best for light/moderate use) Provider Backbone Block size Approx price Effective cost/GB NewsgroupDirect UsenetExpress (+ Supernews, Farm, Viper in multi) 50 GB–2 TB ~$6–$75 ~$0.04–$0.12/GB Usenet.Farm Abavia (NL) 10 GB–several TB very low promo among the cheapest UsenetExpress UsenetExpress 40 GB–2 TB ~$4–$85 ~$0.04–$0.10/GB Newshosting Omicron 25 GB–1 TB promo-priced good for Omicron depth Block accounts from reputable backbones never expire. That\u0026rsquo;s the killer line. A 100 GB block from Usenet.Farm or UsenetExpress for under a tenner is, for most light users, the entire Usenet bill for a year or more.\nCheap Unlimited (best for heavy/tolerant users) Provider Backbone Approx monthly Notes NewsgroupDirect NGD + Supernews + Farm + Viper ~$9/mo, ~$75/yr Most backbone coverage per pound Newshosting Omicron ~$8–9/mo on promo Deep retention cheap Eweka Omicron (deep) mid 2026 promo Best for old content, lower connection cap Where the Budget Trap Hides Three things skim the actual cost of every \u0026ldquo;cheapest\u0026rdquo; list:\nFreemium pricing. Discounts are almost always locked to annual billing. The \u0026ldquo;$9/mo\u0026rdquo; unlimited at NewsgroupDirect drops to closer to $6.25/mo if you pay annually — but if you bail after three months you\u0026rsquo;ve subsidised the annual rate anyway. Work out your real commitment before choosing a billing cycle.\nConnection caps. A £5 monthly plan that gives you 10 connections on a gigabit line is £5 you can\u0026rsquo;t actually use to its full speed. Check the connection allowance matches your line speed — this is where \u0026ldquo;cheap unlimited\u0026rdquo; quietly becomes \u0026ldquo;cheap but slow.\u0026rdquo; For UK fibre users who actually saturate their line, a plan with 100 connections is worth more than it costs.\nBlock expiration and \u0026ldquo;unlimited\u0026rdquo; fine print. Good blocks never expire. But some \u0026ldquo;blocks\u0026rdquo; from fly-by-night resellers quietly expire, and \u0026ldquo;unlimited\u0026rdquo; providers have been known to throttle after heavy use. Buy blocks from a named backbone (Omicron, UsenetExpress, Abavia/Usenet.Farm), not a white-label.\nThe UK FUP Angle No Budget List Mentions Because you asked about value, here\u0026rsquo;s the UK-specific cost trap: Fair Usage Policies. Cheap unlimited plans on UK broadband often sit under a plan that quietly defines \u0026ldquo;unlimited\u0026rdquo; down. And here\u0026rsquo;s the feedback loop — Usenet saturates a line so efficiently that heavy UK users can trip a FUP faster than they\u0026rsquo;d expect.\nThe upshot for budget buyers:\nIf you\u0026rsquo;re a light/moderate UK user, a block avoids FUP risk entirely and is dramatically cheaper. If you\u0026rsquo;re heavy, pay for a genuinely unlimited fibre plan and pick an unlimited Usenet account with high connections — the \u0026ldquo;savings\u0026rdquo; of a cheap low-connection plan get eaten by slow sustained throughput. The Usenet vs torrents guide covers the FUP trade-off in more detail.\nMy Actual Recommendation It splits by usage, and I\u0026rsquo;m not going to force one answer:\nCasual / occasional use: buy a block, not a subscription. A 100 GB block from Usenet.Farm or UsenetExpress is the cheapest genuinely-good option. Full stop.\nModerate but regular use: consider NewsgroupDirect\u0026rsquo;s block accounts — they never expire, and because Grand Slam covers four backbones you get completion failover even on a block. That\u0026rsquo;s unusually good value. If you don\u0026rsquo;t want to think about it, a cheap unlimited works.\nHeavy use on fibre: unlimited wins. NewsgroupDirect\u0026rsquo;s unlimited (~$9/mo, ~$75/yr) is the best price-per-backbone-coverage in the market right now, with 100 connections to actually use your line. → NewsgroupDirect current deals1\nThe Honest Bottom Line The cheapest Usenet provider isn\u0026rsquo;t one name — it\u0026rsquo;s the right account type for your usage. Most people overpay because they buy an unlimited subscription when a block would do. Work out your monthly volume first, then the cheapest option becomes obvious. And remember: cheapest ≠ a white-label discount — a block from a named backbone, or a multi-backbone bundle, is almost always the true value play.\nFurther Reading Not sure a block covers you? Best Usenet Providers UK 2026 compares the full range — including the Omicron vs UsenetExpress vs Abavia structure that shapes real cost. Retention is how you know a cheap spool still has what you want — and PAR2 is the repair budget: Usenet retention explained. When a cheap spool comes up short, the repair playbook is in the PAR2 repair playbook. Want the downloader to use those connections well on a budget machine? SABnzbd vs NZBGet. New here? Start with What is Usenet. Still weighing up whether Usenet is worth paying for at all: Usenet vs torrents. Affiliate link — buying through it earns UsenetPirate a commission at no cost to you. I recommend it anyway; the multi-backbone coverage per pound genuinely beats the single-backbone budget crowd.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","permalink":"https://usenetpirate.co.uk/providers/cheapest-usenet-providers/","summary":"\u003cp\u003e\u0026ldquo;Cheapest Usenet provider\u0026rdquo; is a trap. Every budget roundup on the internet quotes the headline monthly price and stops there, ignoring the data caps, the connection limits, and the fact that you might be paying for a whole unlimited account when a £3 block would cover six months of your actual use.\u003c/p\u003e\n\u003cp\u003eSo let\u0026rsquo;s cost this out properly. Not the marketing price — the \u003cstrong\u003ereal cost for how you actually use Usenet\u003c/strong\u003e — and add the one thing budget lists almost always miss: \u003cstrong\u003ewhich backbone you\u0026rsquo;re on\u003c/strong\u003e, because that silently changes both what \u0026ldquo;cheap\u0026rdquo; gets you and how much usable speed you actually see.\u003c/p\u003e","title":"Cheapest Usenet Providers 2026: Honest Cost Comparison"},{"content":"Getting started with Usenet is fiddlier than it needs to be, mostly because nobody writes down the whole pipeline in one place. This is that one place. Follow it top to bottom and you\u0026rsquo;ll go from knowing nothing to having a fully automated Usenet setup that runs itself — and stays stable when you start pulling hundreds of gigabytes a week.\nA quick honesty note up front: two of the four pieces of this pipeline cost money (a provider and, usually, an indexer). I\u0026rsquo;ve written the cheapest providers guide separately because \u0026ldquo;cheapest\u0026rdquo; and \u0026ldquo;how to set it up\u0026rdquo; are different questions. Here, we\u0026rsquo;re setting things up the right way first — including the UK-specific decisions that trip people up.\nWhat You\u0026rsquo;ll Need The modern Usenet stack has four parts:\nProvider — the server that stores articles. (Paid, ~£5–9/mo or blocks.) Indexer — the searchable catalogue of NZB files. (Often paid for good ones.) Newsreader / downloader — grabs the articles and assembles files. (SABnzbd is the standard.) .nzb file — the pointer that says \u0026ldquo;these specific articles = this file.\u0026rdquo; Optionally, automation on top (Sonarr/Radarr) makes it fully hands-off.\nStep 1: Pick a Provider (and the Backbone Behind It) Choose a provider based on backbone, retention, and completion — I\u0026rsquo;ve costed this out in the UK provider comparison. The single most important starting insight: almost every provider resells someone else\u0026rsquo;s backbone. Pick the storage network first, then shop the front-ends on price.\nThere are three backbones that matter in 2026:\nOmicron — the biggest, deepest spool (Eweka, Newshosting and dozens of resellers). Best for very old content; some front-ends have low connection caps. UsenetExpress — fast, modern, excellent completion on a single coherent spool (UsenetExpress, NewsgroupDirect, ViperNews). Abavia — the classic independent European backbone (Usenet.Farm and a few resellers), strong European peering. For a first account, the sensible default is a provider with SSL, at least 50 connections, and strong completion on new releases — you don\u0026rsquo;t need maximum retention to start. A multi-backbone unlimited makes for the most forgiving first setup, because completion on one spool covers gaps on another. If anyone ever tells you \u0026ldquo;just buy the spool with the most days,\u0026rdquo; remember the PAR2 repair science angle: completion beats a big retention headline every time.\nIf you\u0026rsquo;d rather not commit to a subscription while learning, grab a block (fixed data, never expires) from a reputable backbone — see the cheapest options. Cheap, and you can\u0026rsquo;t waste money while you learn.\nRecommended starting account: a multi-backbone unlimited (or block) from NewsgroupDirect covers the most bases per pound and its Grand Slam plan bundles four backbones in one account, which is unusually forgiving while you learn. See current deals.\nUK ISP selection note Your broadband also determines how fast Usenet actually runs. Key points for UK readers:\nSSL on port 563 is non-negotiable against UK ISP throttling — configure it the moment you add your server (Step 3). Fair Usage Policies: unlimited UK plans often have an unadvertised cap. Usenet saturates a line very efficiently, so heavy users can trip a FUP faster than they\u0026rsquo;d expect. Pick a genuinely unlimited fibre plan or schedule big pulls off-peak. Routing/peering: a spool with good European peering (Abavia/Usenet.Farm) can out-download a \u0026ldquo;deeper\u0026rdquo; spool that\u0026rsquo;s routed poorly to the UK. See the retention guide\u0026rsquo;s ISP section and the best UK providers for why backbone peering matters as much as headline days. Step 2: Get an Indexer You can\u0026rsquo;t browse Usenet like a website — you need an indexer to find binaries. Indexers differ wildly in coverage, freshness, and quality of the NZBs they produce.\nFree/public indexers exist but are hit-or-miss, often slow-indexed and full of dead NZBs. Paid/private indexers are usually a small annual fee and offer far better coverage, faster indexing, and working NZBs. They\u0026rsquo;re worth the money for the automation step to work properly. Newznab indexers expose an API that tools like Sonarr/Radarr hook into — you\u0026rsquo;ll want one that supports this for automation. Sign up for one good indexer first. You can add a second later to improve completion — no single indexer covers everything, and a backup is a common trick. For new users, get comfortable with free options first, then pay once you\u0026rsquo;re sure the pipeline works. The full decision framework is in Usenet indexers explained.\nStep 3: Set Up SABnzbd SABnzbd is the industry-standard downloader. It accepts NZBs, connects to your provider, downloads the articles, verifies with PAR2, extracts, and renames — all unattended. (If you\u0026rsquo;re on constrained low-RAM hardware, see the SABnzbd vs NZBGet comparison before you commit.)\nInstall Windows/macOS: download the installer from sabnzbd.org and run it; it launches a browser-based UI. Linux / NAS / Docker: the classic approach is a Docker container. A minimal docker run -p 8080:8080 -v /your/downloads:/downloads ghcr.io/sabnzbd/sabnzbd gets you up in seconds. Configuration Add your server. In Config → Servers, add your provider\u0026rsquo;s host, username, password, port 563 with SSL enabled (TLS). Set connections to the maximum your plan allows (often 100). Enable TLS on both server (479) and client (478) for header encryption — this is your UK ISP-throttle defence. Set paths. Point Config → General at your complete and incomplete download folders. Keep them on fast storage (SSD or RAID), not the same slow spinning disk as your OS — Usenet saturates drives, and disk speed is a silent bottleneck on big transfers. Enable repairs. SABnzbd handles PAR2 automatically when you open an NZB that includes .par2 files. Number of repair threads: start at 1–2. Test. Download a small NZB from your indexer and watch it land. Large-transfer stability (worth doing now) So you don\u0026rsquo;t learn this the hard way after a hundred gigabytes:\nCap connections to your provider\u0026rsquo;s allowance — more than allowed fragments and slows you down, not speed you up. Queue cleanly. Let one download finish and repair before stacking ten at once; that avoids CPU/RAM meltdown during simultaneous PAR2 repairs. Watch the repair phase. On a big release, PAR2 verification is the CPU-hungry part. If a multi-hundred-GB download slows at the finish line, your disk or CPU is the culprit — not the downloader. SABnzbd fixes a lot for you automatically — missing articles, bad filenames — which is exactly why it beats a bare newsreader for binaries. It also means you get the PAR2 repair budget working for you without thinking about it — and when a repair does stall, the settings that fix it are in repair troubleshooting.\nStep 4: Automation (Sonarr/Radarr) — Optional But Life-Changing This is where Usenet gets properly good. Instead of hunting for NZBs, you install:\nSonarr — watches TV series, grabs NZBs automatically as episodes release. Radarr — does the same for films. Since both feed SABnzbd when you connect an indexer, once it\u0026rsquo;s set up you basically never touch Usenet directly again: a new episode appears, Sonarr finds the NZB on your indexer, hands it to SABnzbd, SABnzbd downloads and renames it into your media folder.\nBoth run great in the same Docker setup as SABnzbd. Expect a half-day to get the integration right the first time — the payoff is years of hands-off downloads.\nStaying Private and Legal in the UK Two things, and I won\u0026rsquo;t sugar-coat either:\nEncryption: your provider-to-you connection should be SSL/TLS (port 563) — mandatory. Some providers (NewsgroupDirect among them) bundle a VPN; a VPN adds protection for your general traffic. Without SSL you\u0026rsquo;re sending plaintext that UK ISPs have previously throttled and can inspect. The Usenet vs torrents guide digs into why SSL beats VPN roulette for Usenet specifically. The legal reality: much of the popular binary traffic on Usenet is copyrighted material. Downloading it in the UK can put you on the wrong side of copyright law regardless of file protection or encryption. Use Usenet legally. Don\u0026rsquo;t treat encryption as a licence to ignore the law where you live. This guide covers the technical setup — you own the legal side. Full Pipeline Recap Indexer ──NZB──\u0026gt; Sonarr/Radarr ──\u0026gt; SABnzbd ──SSL(563)──\u0026gt; Provider │ └──\u0026gt; VERIFY (PAR2) → EXTRACT → RENAME → media folder Automation makes it elegant; without it, it\u0026rsquo;s still a two-click download.\nNext Steps Still wrapping your head around the what? What is Usenet and how does it work?. The retention misconception that makes people overpay — and the PAR2 science: explained here. Choose what to pay for: best providers UK and cheapest providers. Choosing between this and torrents, with the UK ISP angle: Usenet vs torrents. Which downloader for your hardware: SABnzbd vs NZBGet. ","permalink":"https://usenetpirate.co.uk/guides/how-to-get-started-with-usenet-2026/","summary":"\u003cp\u003eGetting started with Usenet is fiddlier than it needs to be, mostly because nobody writes down the whole pipeline in one place. This is that one place. Follow it top to bottom and you\u0026rsquo;ll go from knowing nothing to having a fully automated Usenet setup that runs itself — and stays stable when you start pulling hundreds of gigabytes a week.\u003c/p\u003e\n\u003cp\u003eA quick honesty note up front: two of the four pieces of this pipeline \u003cstrong\u003ecost money\u003c/strong\u003e (a provider and, usually, an indexer). I\u0026rsquo;ve written the \u003cstrong\u003e\u003ca href=\"/providers/cheapest-usenet-providers/\"\u003echeapest providers guide\u003c/a\u003e\u003c/strong\u003e separately because \u0026ldquo;cheapest\u0026rdquo; and \u0026ldquo;how to set it up\u0026rdquo; are different questions. Here, we\u0026rsquo;re setting things up the right way first — including the UK-specific decisions that trip people up.\u003c/p\u003e","title":"How to Get Started with Usenet: 2026 Setup Guide"},{"content":"Once you\u0026rsquo;ve got a Usenet provider and an indexer (see the setup guide), the next decision is which downloader to run: SABnzbd or NZBGet. These are the two giants of the binaries world, and people argue about them like sports teams. Let me settle it for you with actual reasoning instead of tribal loyalty.\nShort version: most people should use SABnzbd. NZBGet is only clearly better in two narrow situations. Here\u0026rsquo;s why — and at the end I\u0026rsquo;ll dig into the large-transfer stability question, because on modern UK fibre that\u0026rsquo;s often the deciding factor nobody mentions.\nWhat They Both Do Both SABnzbd and NZBGet do the same core job: take an NZB, connect to your provider over SSL, pull the articles, verify with PAR2, extract, and rename the finished file. Both integrate with Sonarr/Radarr and both support any provider you can find. On the fundamentals — speed, completion, SSL, automation — they\u0026rsquo;re functionally tied.\nThe real differences are in resource usage, maturity, and where you run them.\nSABnzbd: The Safe Default SABnzbd is the one most guides recommend and the one with the biggest community. It\u0026rsquo;s written in Python, mature, and relentlessly maintained.\nWhy you\u0026rsquo;ll like it:\nMost documented. Every Sonarr/Radarr/automation guide assumes SABnzbd. You\u0026rsquo;ll never be stuck with no tutorial. Best default setup UX. The browser UI is polished, the wizard configures your provider quickly, and it walks you through the first download. Easiest to debug. Big user base means almost any error you hit is already answered on its forum. Gentle concurrency defaults. It handles high connection counts reliably without crashing, which matters on gigabit fibre. The downside: SABnzbd is heavier on RAM and CPU, especially for PAR2 repairs and post-processing on a busy library. On an old PC or a low-spec NAS it can feel sluggish. On modern hardware you won\u0026rsquo;t notice.\nNZBGet: The Lightweight Option NZBGet is written in C++ and is dramatically lighter on resources. On the right hardware it\u0026rsquo;s both faster and more efficient than SABnzbd.\nWhy you might use it:\nMinimal RAM/CPU. It\u0026rsquo;s the classic choice for a potato NAS, a Raspberry Pi, or any always-on box with limited RAM. It\u0026rsquo;ll saturate gigabit on hardware where SABnzbd chokes. Raw speed. On modern multi-core systems NZBGet can outperform SABnzbd slightly during heavy repair. Efficient post-processing. Uses far less juice while unpacking and repairing. The real catch: NZBGet\u0026rsquo;s development effectively stalled. It hasn\u0026rsquo;t seen the level of active development SABnzbd has, recent releases are sparse, and some users have hit bugs that simply don\u0026rsquo;t get fixed. For a piece of software you\u0026rsquo;ll run unattended 24/7, \u0026ldquo;not actively maintained\u0026rdquo; is a genuine risk.\nLarge-Transfer Stability: The Decision Nobody Talks About Here\u0026rsquo;s the section most comparisons skip, and it\u0026rsquo;s the one that bites hardest on modern UK fibre. \u0026ldquo;Which is faster\u0026rdquo; is the wrong question on a single download. The real question is which one stays stable when you run hundreds of gigabytes a week.\nThe PAR2/repair bottleneck Both tools download fast — the difference shows up in verification and repair. On a modern release with 5–10% parity (see the PAR2 repair science section for why that budget is fixed), a repair is a CPU- and I/O-heavy Reed–Solomon decode across every byte of the file. When a repair stalls or fails, the fix routine is in fixing a failed repair.\nSABnzbd does this in Python via par2cmdline. It\u0026rsquo;s reliable and predictable, but on a low-end CPU it makes the machine feel sluggish while a big download is finishing its repair. NZBGet built verifier and repair into its C++ core and parallelises it well. On multi-core hardware it can chew through a repair noticeably faster, and with far less RAM than SABnzbd. The catch: for that speed advantage to matter, the repair has to be the bottleneck — i.e. you\u0026rsquo;re on constrained hardware and your CPU is genuinely the limiting factor. On any half-decent modern machine, SABnzbd repairs fast enough that the difference is irrelevant.\nSustained throughput on gigabit On a line that\u0026rsquo;s saturated for hours, the failure mode isn\u0026rsquo;t peak speed — it\u0026rsquo;s long-run stability: memory bloat over a multi-hour transfer, tempera spikes, and the client quietly backing off connections.\nSABnzbd\u0026rsquo;s Python overhead means it uses more RAM the longer and busier it runs, but it\u0026rsquo;s also the one with a huge installed base reporting the exact multi-hour/multi-day soak scenarios on every combination of hardware. That soak-testing is real-world insurance. NZBGet sips RAM and stays flat over long transfers — if it\u0026rsquo;s maintained on your hardware. The risk is a stale binary with a bug that someone else hit and nobody\u0026rsquo;s fixed, at a scale (days of uptime) where bugs surface. High-speed performance rules of thumb For getting genuinely fast, stable transfers, the downloader matters less than three things that apply to both:\nRight connection count. Set it to what your provider allows (often 100). Too few and you plateau below line speed; too many and you fragment. Both tools handle this via Settings → Servers → Connections. Fast, non-fragmented disk. Usenet saturates drives. Put incomplete/ and complete/ on SSD or a RAID, never on the same slow spinning disk as the OS. SSL on port 563. Encrypted links slightly raise CPU but keep UK ISPs from shaping you (see the UK throttling section). Both tools do SSL fine; enable it on server and client connections. The Decision, Simplified Factor SABnzbd NZBGet Speed (typical) Great Excellent on multi-core Large-transfer stability ✅ Huge soak-tested base ⚠️ Flat RAM, but stale bugs Resource use Heavier Much lighter RAM on low-spec boxes Poor fit The reason to choose it Active development ✅ Active ⚠️ Stalled Community / guides ✅ Huge Smaller Automation integration ✅ Excellent ✅ Excellent Ease of setup ✅ Best Fine Use SABnzbd unless you\u0026rsquo;re running on a constrained device (low-RAM NAS, old Pi) and that device is struggling. That\u0026rsquo;s the honest dividing line. If you\u0026rsquo;re on a normal computer, a decent NAS, or a Docker host, SABnzbd is the better long-term bet — active development and the biggest community outrank a marginal speed win.\nIf your whole point is squeezing maximum throughput from a 2 GB Pi, NZBGet is arguably still the right call in 2026.\nSetup Notes for Both SSL: whichever you pick, configure SSL/TLS on port 563 for both the download (server) and, where supported, the control (client) connections. See the privacy section of the setup guide. Connections: set the connection count to the max your provider allows; both tools handle this fine. PAR2: both auto-handle .par2 repair files from your indexer\u0026rsquo;s NZBs. More repair threads = faster repair but more CPU. Start at 1–2, raise only if a big repair feels slow. Stability: for multi-hundred-GB weeks, point both tools at SSD for the download dir, cap the connection count to your provider\u0026rsquo;s allowance, and let a completed transfer queue cleanly rather than stacking ten downloads at once. Docker: both have solid official images; run them behind your media automation stack. Which Provider Feeds It? The downloader is only as good as the spool it talks to. If you\u0026rsquo;re still deciding where to point SABnzbd or NZBGet, the honest comparisons are here:\nBest Usenet Providers UK 2026 — the full roundup. Cheapest Usenet providers — blocks vs unlimited, costed honestly. Usenet retention explained — the number everyone overpays for, plus the PAR2 science. And if you landed here cold: what even is Usenet?.\n","permalink":"https://usenetpirate.co.uk/guides/sabnzbd-vs-nzbget/","summary":"\u003cp\u003eOnce you\u0026rsquo;ve got a Usenet provider and an indexer (see the \u003cstrong\u003e\u003ca href=\"/guides/how-to-get-started-with-usenet-2026/\"\u003esetup guide\u003c/a\u003e\u003c/strong\u003e), the next decision is which \u003cstrong\u003edownloader\u003c/strong\u003e to run: SABnzbd or NZBGet. These are the two giants of the binaries world, and people argue about them like sports teams. Let me settle it for you with actual reasoning instead of tribal loyalty.\u003c/p\u003e\n\u003cp\u003eShort version: \u003cstrong\u003emost people should use SABnzbd.\u003c/strong\u003e NZBGet is only clearly better in two narrow situations. Here\u0026rsquo;s why — and at the end I\u0026rsquo;ll dig into the \u003cstrong\u003elarge-transfer stability\u003c/strong\u003e question, because on modern UK fibre that\u0026rsquo;s often the deciding factor nobody mentions.\u003c/p\u003e","title":"SABnzbd vs NZBGet: Which Usenet Downloader Should You Use?"},{"content":"You can buy the fastest, deepest Usenet provider on earth and still find nothing, because Usenet has no built-in search. Providers store articles; they don\u0026rsquo;t catalogue them in a way you can browse. Finding the specific binaries you want is the job of an indexer — and choosing the right one is often the difference between a setup that \u0026ldquo;just works\u0026rdquo; and one that\u0026rsquo;s forever missing files.\nThis guide explains how indexers actually work, why paid and free ones differ by a mile, and — in the NZB quality and PAR2 section below — how the indexer\u0026rsquo;s output quietly decides whether your downloads repair cleanly or fail. If you\u0026rsquo;re brand new, read what is Usenet first, then come back.\nWhat an Indexer Actually Is An indexer is a service that crawls Usenet, reads the article headers, and builds a searchable database of what\u0026rsquo;s available — turning into a catalogue what would otherwise be a fire hose of unsearchable binary posts. When it finds a post, it generates an NZB file: a small pointer that lists exactly which articles make up that binary and which newsgroups hold them.\nYour downloader (SABnzbd) opens that NZB and pulls those articles straight from your provider. So the flow is:\nIndexer ──searches──\u0026gt; finds post │ └───── NZB ──────\u0026gt; SABnzbd ──articles──\u0026gt; Provider No indexer, nothing to search, no NZBs, no downloads. It\u0026rsquo;s a mandatory piece of the stack.\nThe Two Big Differences: Free vs Paid The quality gap between free and paid indexers is enormous and directly affects your completion.\nFree indexers Cover a limited slice of Usenet. Index slowly — new content shows up late, if at all. Often local to one backbone\u0026rsquo;s feed or missing the full global picture. Generally lower-quality NZBs with more dead or incomplete references. They\u0026rsquo;re fine for dabbling and for testing your pipeline before you spend money. Don\u0026rsquo;t build your permanent setup on them.\nPaid/private indexers Pull (typically) from richer, faster feeds and index new content more or less instantly — which is critical for automation catching things as they post. Produce higher-quality NZBs that include PAR2 repair files and sensible naming, so SABnzbd verifies and renames cleanly. Are the difference between Sonarr/Radarr grabbing a release the moment it\u0026rsquo;s out vs. missing it. The catch: there\u0026rsquo;s no Yellow Pages of indexers. Most rely on community reputation, invite systems, or registration windows. That friction is half the reason the space is still full of mediocre options and why having a second indexer as a backup is a common trick.\nNZB Quality and the PAR2 Link: The Part Most Guides Miss Here\u0026rsquo;s the angle most indexer guides never connect: the indexer\u0026rsquo;s NZB is what feeds your PAR2 repair budget.\nA good NZB includes three things that a bad one doesn\u0026rsquo;t:\nPAR2 parity files. The NZB lists the .par2 files as part of the post. SABnzbd auto-downloads them and uses the parity to repair missing articles. A poor-quality NZB can omit or mis-point the parity, silently robbing you of your repair headroom. Correct article references. If the NZB\u0026rsquo;s article IDs are wrong or half-dead, SABnzbd spends transfers fetching nothing and hits a completion wall that PAR2 can\u0026rsquo;t rescue. Sensible naming. Clean, consistent names let automation (Sonarr/Radarr) match releases reliably and let SABnzbd rename finished files correctly. Garbage names mean automation misses releases even when the data is there. So the \u0026ldquo;free indexer is fine\u0026rdquo; logic has a hidden cost: free NZBs are more likely to be missing parity or carry dead references, which means you burn your finite repair budget before you even start. This is why the quality of the NZB — not just whether the indexer \u0026ldquo;finds\u0026rdquo; something — is what separates a setup that \u0026ldquo;just works\u0026rdquo; from one that\u0026rsquo;s permanently repairing.\nThe other link: indexer freshness interacts with retention/completion. An indexer that indexes slowly may hand you a release that\u0026rsquo;s already partway out of your provider\u0026rsquo;s clean coverage window, on an older post where thinned articles eat into parity headroom. Fast indexing keeps you inside high-completion territory where PAR2 rarely has to work hard. When it does work — and fails — the fixes live in when a repair fails, and why.\nNewznab and Automation If you\u0026rsquo;re using Sonarr/Radarr automation — and you should — you need an indexer that supports the Newznab API. Newznab is the de-facto standard protocol that lets automation tools query an indexer automatically: it fetches search results and hands matching NZBs to SABnzbd without you ever opening the indexer\u0026rsquo;s site.\nWhen you set up Sonarr/Radarr you\u0026rsquo;ll add your indexer by URL and API key. Choose one with Newznab support or you lose the hands-off automation that makes Usenet great.\nHow to Choose an Indexer There\u0026rsquo;s no single right answer, but the decision framework is:\nStart free to prove your pipeline works (provider + SABnzbd + one free indexer, grab one small NZB). Add a paid indexer for real use — prioritise freshness (fast indexing) and NZB quality (complete parity, clean naming, valid references) over raw group count. The PAR2 link above is exactly why quality beats coverage. Consider a second indexer once you rely on it, since no single indexer is 100% complete. Two good indexers markedly improve successful pulls. Prefer Newznab-compatible ones so automation hooks in cleanly. Do I Recommend Any Specific One? I\u0026rsquo;m not hiding an affiliate deal behind this — there isn\u0026rsquo;t one, and I deliberately keep indexers recommendation-free here. Indexer quality and availability shift too often for a static list to stay honest, and sign-ups are frequently closed or invite-gated. Follow the decision framework above instead of chasing a \u0026ldquo;best indexer\u0026rdquo; listicle that\u0026rsquo;s six months old, because those lists are exactly where the marketing nonsense lives.\nTying It Back Together An indexer is only half the speed equation — the other half is your retention and completion, which depends on the backbone behind your provider. That\u0026rsquo;s why the honest provider roundup exists:\nBest Usenet Providers UK 2026 — which backbone genuinely completes best (Omicron vs UsenetExpress vs Abavia). Omicron vs UsenetExpress — the two big backbones compared head to head. Usenet retention explained — why the headline number misleads, and how PAR2 repair binds to it. Cheapest Usenet providers — so a good indexer doesn\u0026rsquo;t blow your budget. SABnzbd vs NZBGet — the downloader your indexer feeds into. Need the Whole Picture? What is Usenet and how does it work? 2026 setup guide — from zero to automated, step by step. Usenet vs torrents — if you\u0026rsquo;re still deciding whether this is worth it at all. ","permalink":"https://usenetpirate.co.uk/guides/usenet-indexers-explained/","summary":"\u003cp\u003eYou can buy the fastest, deepest Usenet provider on earth and still find nothing, because \u003cstrong\u003eUsenet has no built-in search.\u003c/strong\u003e Providers store articles; they don\u0026rsquo;t catalogue them in a way you can browse. Finding the specific binaries you want is the job of an \u003cstrong\u003eindexer\u003c/strong\u003e — and choosing the right one is often the difference between a setup that \u0026ldquo;just works\u0026rdquo; and one that\u0026rsquo;s forever missing files.\u003c/p\u003e\n\u003cp\u003eThis guide explains how indexers actually work, why paid and free ones differ by a mile, and — in the \u003cstrong\u003e\u003ca href=\"/guides/usenet-indexers-explained/#nzb-quality-and-the-par2-link-the-part-most-guides-miss\"\u003eNZB quality and PAR2 section below\u003c/a\u003e\u003c/strong\u003e — how the indexer\u0026rsquo;s output quietly decides whether your downloads repair cleanly or fail. If you\u0026rsquo;re brand new, read \u003cstrong\u003e\u003ca href=\"/guides/what-is-usenet/\"\u003ewhat is Usenet\u003c/a\u003e\u003c/strong\u003e first, then come back.\u003c/p\u003e","title":"Usenet Indexers Explained: How to Find Anything on Usenet"},{"content":"Every Usenet provider brags about retention. \u0026ldquo;5,000 days!\u0026rdquo; \u0026ldquo;6,000 days!\u0026rdquo; Bigger must be better, right?\nNot necessarily. Retention is the most misused number in the entire industry, and it\u0026rsquo;s the one most likely to make you overpay. But there\u0026rsquo;s a second, quieter piece of the puzzle that almost nobody explains: PAR2 repair science. Retention is the window in which content exists; PAR2 is what actually rescues you when content inside that window is incomplete. This guide covers both — why the headline retention number misleads you, and why your downloader\u0026rsquo;s ability to repair a broken file often matters more than a couple of extra thousand days of storage.\nWhat Retention Actually Is Retention is simply how long a provider stores every article on its servers before deleting it. Measured in days. If a provider has 5,000 days of retention and an article is posted today, it\u0026rsquo;ll be purged roughly 5,000 days from now — assuming the provider doesn\u0026rsquo;t expand its spool in the meantime (they usually do, which is why these numbers climb year over year).\nThat\u0026rsquo;s the whole definition. Everything else in this guide is about where that definition gets fudged.\nWait — why isn\u0026rsquo;t retention \u0026ldquo;forever\u0026rdquo;? Storage costs money. Usenet ingests an enormous volume of data every day — on the order of hundreds of terabytes per day across the network. Keeping all of that for 16 years is an expensive proposition. Providers trade off retention against how much hardware they want to pay for. That\u0026rsquo;s why different backbones offer different retention.\nThis is also the root of a specific UK angle: because you\u0026rsquo;re physically downloading gigabytes across undersea links and your ISP\u0026rsquo;s infrastructure, a deep-retention spool that\u0026rsquo;s hosted across the Atlantic is often slower in practice than a shallower one hosted closer to home — no matter how many days its marketing page quotes. More on that in the large-transfer stability section of the downloader guide.\nThe Crucial Distinction: Full vs \u0026ldquo;Up To\u0026rdquo; Retention Here\u0026rsquo;s the trap. Providers quote retention as \u0026ldquo;up to X days.\u0026rdquo; That\u0026rsquo;s the maximum age of the oldest articles they\u0026rsquo;ll ever serve. It does not mean every article that age is actually there.\nIn practice, providers usually have two retention layers:\nFull retention — the articles the provider is genuinely storing in full and can serve on demand. Popular retention — older articles that are still listed in the headers but may be progressively thinned, reprocessed, or only partially available. The headline \u0026ldquo;6,000 days\u0026rdquo; is almost always the maximum, and the complete-coverage number is meaningfully lower. This is a huge reason cheap providers can quote giant retention numbers while quietly having terrible gaps on older content. My honest take in the provider roundup explains how this shows up in practice.\nRetention vs Completion: The Part Everyone Skips You\u0026rsquo;ll hear retention and completion used interchangeably. They are not the same thing, and completion is the one that actually affects you.\nRetention = how long articles are stored. Completion = how complete a given binary is when you download it — i.e. what percentage of its articles your provider can actually serve. A provider can advertise 6,000 days of retention and still hand you a 97% file on a popular post that\u0026rsquo;s three weeks old, because chunks of it were never propagated to their spool or got taken down. Retention tells you the window; completion tells you the reality inside that window.\nFor everyday use, completion matters far more than the retention number. A provider with 5,000 days and 99% completion beats one with 6,000 days and 96% completion, almost every time.\nWhy completion differs between backbones Completion differences come down to:\nPeering/uptake. How completely a backbone ingests the full global feed. Bigger backbones (Omicron) ingest a large share of the total feed, so they complete better across the board. Takedown policies. Providers that aggressively honour removals lose articles faster than those that don\u0026rsquo;t, which hits completion on anything affected. Propagation. With tens of terabytes a day in motion, glitches mean some articles simply never land on a given spool. More independent backbones in one account can catch what another misses — which is exactly the logic behind multi-backbone providers like NewsgroupDirect\u0026rsquo;s Grand Slam (NGD + Supernews + Usenet.Farm + ViperNews in one account). See the best providers comparison for why that\u0026rsquo;s worth money, and the Omicron vs UsenetExpress head-to-head for the two backbones behind most accounts. The PAR2 Repair Science Section You Won\u0026rsquo;t Find Elsewhere Here\u0026rsquo;s where retention guides usually stop — and where they should dig in. Because when a provider hands you a 97% file, the question isn\u0026rsquo;t \u0026ldquo;which backbone was it?\u0026rdquo; It\u0026rsquo;s \u0026ldquo;can my downloader repair the missing 3%?\u0026rdquo;\nWhat PAR2 actually is PAR2 (Parity Archive, volume 2) is an error-correction scheme layered on top of a release. Poster software (SRR, QuickPar, or the tools that build a release) generates parity files alongside the main binaries. Those parity files encode redundant data: enough that your downloader can reconstruct any missing or corrupt article from the parity alone.\nThink of it like a crosswords grid. Every row and column has checksum clues (the parity). If one cell (article) is missing, you can still deduce what belongs in that cell from the other clues in its row and column — you don\u0026rsquo;t need the cell itself. PAR2 works the same way, but with far more redundancy at scale.\nThe physics of a repair This is the bit that surprises people, and it\u0026rsquo;s directly relevant to retention:\nThe fraction of a post\u0026rsquo;s data you can repair from PAR2 is capped by the parity volume included in the release. Posters typically add 5–10% parity. So if a file is missing more than ~10% of its articles, PAR2 cannot save it — the repair will fail. The further out of the retention window you pull, the more articles tend to be thinned or missing, eating into that parity headroom. This is the real, physical union of retention and repair: a deep-retention spool gives you the same 5–10% repair budget; it just means you\u0026rsquo;re more likely to be pulling from complete coverage in the first place. PAR2 repair is CPU-bound and I/O-heavy. During a big repair, SABnzbd or NZBGet runs a Reed–Solomon decode across the whole file. On a low-RAM NAS or an underpowered Pi, this is exactly where a fast download stalls at the finish line. See the SABnzbd vs NZBGet guide for which downloader handles this science better. For the practical side — the exact settings and what to do when a repair fails — see the practical repair guide. Why \u0026ldquo;just get more newsgroups\u0026rdquo; philosophies mislead A common (and wrong) framing is that completion is purely a function of how much you can grab. In reality, repair is bounded by parity, not by retrieving more raw articles. If a release ships with 6% parity, no amount of extra fetching replaces articles that are missing network-wide from the spool — PAR2 can only reconstruct up to that 6% cap. This is precisely why paying for broad, high-completion backbones (which keep you inside working coverage) beats paying for a single deep-but-thinly-peered spool.\nThe practical rule Recent releases with 5–10% parity rarely need repair at all — completion is near-total. Older, less-popular content is where both retention gaps and missing articles stack up. Here your PAR2 budget is your lifeline, and a provider with better completion covers more of that budget than a provider with more headline days. So when someone tells you \u0026ldquo;just buy the spool with the most days,\u0026rdquo; the PAR2-aware (and honest) answer is: buy the spool most likely to give you near-complete articles, so your limited parity budget is spent only on genuine stragglers — not on making up for systemic gaps.\nHow Retention Should Affect Your Buying Decision How deep do you actually need to go? Work backwards from your content age:\nRecent releases: you need barely any retention. Even a cheap, modest-retention provider handles this fine, and PAR2 rarely even activates. Content up to a few years old: ~2,000–4,000 days is comfortable. Ten-year-old archives: you want maximum retention and top completion, because old, obscure content is exactly where thin spools fall apart first — and where your PAR2 budget can\u0026rsquo;t bail you out. Overpaying for a giant retention number you\u0026rsquo;ll never use is the single most common budget mistake. If you mostly grab new releases, spend your money on completion and speed, not an extra 2,000 days of retention you\u0026rsquo;ll never touch.\nBlocks are retention-safe Because good block accounts never expire, a block from a deep-retention backbone is a cheap way to hedge: you buy access to the deep spool once, and it\u0026rsquo;s still valid when you eventually need an old article. My cheapest providers guide costs this out.\nDoes Retention Grow Forever? No, and this is worth understanding. Retention climbs because providers keep expanding storage, not because articles magically persist. There are physical and financial limits, and the rate the network ingests data keeps growing. At some point providers may hold retention flat or even trim it on less-popular groups. This is manageable by most users, but \u0026ldquo;big number now\u0026rdquo; isn\u0026rsquo;t a guarantee for the future — which is another quiet argument for having access to more than one backbone.\nA Note on the UK ISP Angle Retention is a storage promise, not a speed promise. In the UK, whether a deep spool is actually usable is also a question of where that spool lives and how your ISP routes to it. UK ISPs have historically throttled Usenet traffic, and while modern SSL on port 563 defeats the throttling that was once baked into the network, routing quality to different backbones still varies by provider and by the time of day. A spool with better European peering can genuinely out-download a \u0026ldquo;deeper\u0026rdquo; spool routed badly in the UK. This is another reason the backbone (and its peering) matters more than the brand — covered in the best providers UK comparison.\nThe Bottom Line Retention = how long articles are kept. Completion = how complete the ones you actually download are. PAR2 = the repair budget that rescues incomplete downloads — but it\u0026rsquo;s capped by the parity a release ships with (usually 5–10%), so it can\u0026rsquo;t fix systemic gaps. The headline retention number is a maximum, not a guarantee of full coverage. For most people, completion and a working PAR2 budget beat raw retention. Buy retention depth only if you genuinely pull old content. Further Reading See how it plays out provider-to-provider: Best Usenet Providers UK 2026. Which downloader handles the PAR2 repair science best: SABnzbd vs NZBGet. Understanding the basics first? What is Usenet and how does it work?. Pay is the other half: Cheapest Usenet providers. Actually getting online: 2026 setup guide. ","permalink":"https://usenetpirate.co.uk/guides/usenet-retention-explained/","summary":"\u003cp\u003eEvery Usenet provider brags about retention. \u0026ldquo;5,000 days!\u0026rdquo; \u0026ldquo;6,000 days!\u0026rdquo; Bigger must be better, right?\u003c/p\u003e\n\u003cp\u003eNot necessarily. Retention is the most misused number in the entire industry, and it\u0026rsquo;s the one most likely to make you overpay. But there\u0026rsquo;s a second, quieter piece of the puzzle that almost nobody explains: \u003cstrong\u003ePAR2 repair science.\u003c/strong\u003e Retention is the \u003cem\u003ewindow\u003c/em\u003e in which content exists; PAR2 is what actually rescues you when content inside that window is incomplete. This guide covers both — why the headline retention number misleads you, and why your downloader\u0026rsquo;s ability to \u003cstrong\u003erepair\u003c/strong\u003e a broken file often matters more than a couple of extra thousand days of storage.\u003c/p\u003e","title":"Usenet Retention Explained: PAR2 Repair Science vs Raw Headline Numbers"},{"content":"If you\u0026rsquo;ve ever downloaded anything at scale, you\u0026rsquo;ve had this thought: should I use Usenet or torrents? This is the honest, no-BS comparison. I use both — Usenet for speed and reliability, torrents when I can\u0026rsquo;t justify paying for something niche — so let\u0026rsquo;s settle it properly.\nThe headline: for speed, reliability and automation, Usenet genuinely wins. For \u0026ldquo;free and no central infrastructure,\u0026rdquo; torrents win. Here\u0026rsquo;s the full breakdown so you can decide on your own use case.\nThe Head-to-Head Speed Usenet: downloads are served by professional server farms over your full connection speed. SABnzbd opens dozens of connections (up to 100) and saturates a gigabit line. The only limit is your broadband and your provider\u0026rsquo;s network. There is no throttling based on swarm health. Torrents: speed depends entirely on how many seeders are online and how healthy the torrent is. A hot, well-seeded release rips along; an obscure one crawls at a few KB/s or stalls entirely. You can\u0026rsquo;t control it. Winner: Usenet, decisively — unless the torrent happens to be well-seeded, in which case they\u0026rsquo;re close.\nReliability \u0026amp; availability Usenet: content is on servers, 24/7. You download when you want; it\u0026rsquo;s there for years (see retention). No dependence on people staying online. Torrents: content exists only while someone seeds it. Old or niche content routinely dies as torrents lose seeders and get removed. A download that fails at 99% with no seeders is a genuine problem with no fix. Winner: Usenet.\nAutomation This is the killer feature that most comparisons bury.\nUsenet: the entire pipeline is scriptable and trustworthy. Sonarr/Radarr watch for releases, grab the NZB from an indexer, hand it to SABnzbd, which verifies with PAR2 and renames the file. Downloads just happen in the background, forever, without you touching it. Torrents: automation exists (Sonarr/Radarr support torrent clients) but hits the seed ratio problem — you\u0026rsquo;re expected to seed back, public trackers are unreliable, and failed torrents need manual babysitting. Winner: Usenet. If you value \u0026ldquo;set it up once and it just works,\u0026rdquo; this alone justifies usenet.\nRetention / old content Usenet: providers keep binaries for years — top tier over 15 years. Old files stay findable. Torrents: old content is the most likely thing to die. Obscure older releases are hard or impossible to find seeded. Winner: Usenet.\nPrivacy \u0026amp; legal exposure Usenet: with SSL/TLS on port 563 your download content isn\u0026rsquo;t visible in transit to your ISP as content, though you\u0026rsquo;re still connecting to a known Usenet provider. It\u0026rsquo;s a private pipe for your traffic. Torrents: you\u0026rsquo;re publishing your IP to the whole swarm. Anyone (including rights holders and ISPs) can watch. Using a VPN is essentially mandatory, and no-P2P VPN providers make torrenting a problem. Winner: Usenet on the privacy/technical axis. But legal exposure is a separate matter for what you download on either network — encryption doesn\u0026rsquo;t make unlawful downloads lawful.\nCost Usenet: you pay. A provider (typically £5–9/mo unlimited or a cheaper block) and usually an indexer (small annual fee). Real cost is low but it\u0026rsquo;s not free. Torrents: free, apart from a VPN if you\u0026rsquo;re smart. Winner: Torrents.\nSpeed ceiling on extreme connections At truly extreme symmetric lines, always-on torrents with huge upload can saturate a line too; but for the typical UK fibre user, Usenet consistently hits full line speed and torrents are unreliable at it.\nWinner: Usenet.\nThe UK ISP Angle: Throttling Is the Whole Game This is where the comparison gets genuinely UK-specific, and it\u0026rsquo;s worth its own section.\nUK ISPs have a history of throttling both torrents and Usenet. Back in the days of plaintext Usenet, UK providers famously applied traffic shaping to the protocols, telling users to shove off to off-peak hours to get their \u0026ldquo;allowance.\u0026rdquo; Modern UK broadband is a different beast, but the legacy of that shaping shapes how you should configure both tools:\nUsenet: the fix is SSL/TLS on port 563. Encrypted Usenet traffic defeats traditional content-based throttling, because the ISP can\u0026rsquo;t inspect what\u0026rsquo;s inside the tunnel — only that you\u0026rsquo;re talking to a known Usenet provider\u0026rsquo;s IP. Almost every reputable provider supports port 563 with SSL; if one doesn\u0026rsquo;t, walk away. The residual risk is destination-based shaping, where an ISP throttles a whole server IP block regardless of encryption. That\u0026rsquo;s why peering and routing quality to a specific backbone matters (see the best UK providers roundup). Torrents: the fix is a VPN, but here\u0026rsquo;s the twist — UK ISPs are famous for throttling (and occasionally blocking) P2P traffic entirely, and no-P2P VPN providers make it worse. With torrents you must use a VPN anyway to hide your IP from the swarm, so the ISP-throttle problem and the privacy problem collide into one mandatory-VPN requirement. Fair Usage Policies (FUP): many UK unlimited broadband plans have an unadvertised FUP. High-volume downloading — whether Usenet or torrents — can trip a fair-use flag. Because Usenet saturates a line far more efficiently than torrents, heavy Usenet users tend to hit those volume caps faster, which is an honest downside worth planning around (schedule big pulls, use off-peak windows, and be aware of your plan\u0026rsquo;s limits). The practical takeaway for UK readers: on fibre, Usenet is both faster and easier to keep unthrottled (SSL beats playing VPN roulette), but it\u0026rsquo;s also more efficient at burning through your FUP allowance. Torrents are free but demand a VPN and tolerate unpredictable speed. For UK users who want reliable, full-line speed, Usenet is the cleaner answer — provided you use SSL on port 563.\nLarge Transfer \u0026amp; Stability: What Actually Happens at Scale People compare tools on a single download and miss the aggregate picture. Real heavy use means hundreds of gigabytes a week, dozens of simultaneous downloads, sustained line saturation. At that scale the two differ a lot:\nUsenet handles sustained throughput gracefully because it\u0026rsquo;s server-driven. Your downloader opens a fixed pool of connections and keeps them filled. The failure mode isn\u0026rsquo;t \u0026ldquo;the swarm died halfway\u0026rdquo; — it\u0026rsquo;s rare and retriable, and PAR2 covers the occasional missing article (read the PAR2 repair science section for why that budget is bounded, and PAR2 repair in practice for fixing it when it fails). Torrents degrade under scale. A queue of 50 torrents means 50 tracker pings, 50 slow-start handshakes, and constant churn of peers joining and leaving. On asymmetric UK fibre (cheap upload), torrents can\u0026rsquo;t upload back fast enough to build the ratio that keeps your speeds high — a fundamental mismatch for British lines in particular. For anyone who downloads a lot, Usenet\u0026rsquo;s stability under sustained saturation is the difference between \u0026ldquo;set and forget\u0026rdquo; and \u0026ldquo;constantly babysitting a queue.\u0026rdquo; See the SABnzbd vs NZBGet guide for how the downloader keeps that throughput stable on a big transfer.\nThe Scorecard Factor Usenet Torrents Speed (typical UK fibre) ✅ Saturated ⚠️ Seed-dependent Reliability / availability ✅ Servers, always up ❌ Dies when seeds die Automation ✅ Excellent ⚠️ Ratio \u0026amp; babysitting Old / niche content ✅ Years of retention ❌ Dies off Privacy of traffic ✅ SSL pipe ❌ IP public to swarm UK ISP throttling ✅ Beaten by SSL/563 ⚠️ Needs a VPN, P2P-shaped Cost £5+/mo or block Free (you supply time) Set-up effort Higher Low Usenet wins on everything except cost and simplicity. For anyone who downloads regularly and wants it to just work, Usenet is the better tool. If you hardly ever download and don\u0026rsquo;t care about automation or old content, a torrent client (with a VPN) is genuinely fine and free.\nWhat I\u0026rsquo;d Recommend Regular or heavy user who wants hands-off reliability: get a Usenet provider + one indexer, set up SABnzbd and Sonarr/Radarr, and tear it up. See the 2026 setup guide. Very casual user: torrents with a VPN are fine. Don\u0026rsquo;t pay for Usenet you won\u0026rsquo;t use. UK fibre user who hates throttling and wants full line speed: Usenet with SSL on port 563 is the cleaner path. Choose a provider with good routing/peering to the UK — see best providers UK. Mixed use: do both. Usenet for the stuff that matters and the automation; torrents for the odd niche release a good indexer can\u0026rsquo;t find. Why The Next Steps Are Easy Pick a provider without getting sold to: Best Usenet Providers UK 2026. Work out the budget reality: Cheapest Usenet providers. Understand the retention numbers (and PAR2): Usenet retention explained. Pick the downloader that keeps big transfers stable: SABnzbd vs NZBGet. New to the concept entirely? What is Usenet?. ","permalink":"https://usenetpirate.co.uk/guides/usenet-vs-torrents/","summary":"\u003cp\u003eIf you\u0026rsquo;ve ever downloaded anything at scale, you\u0026rsquo;ve had this thought: \u003cem\u003eshould I use Usenet or torrents?\u003c/em\u003e This is the honest, no-BS comparison. I use both — Usenet for speed and reliability, torrents when I can\u0026rsquo;t justify paying for something niche — so let\u0026rsquo;s settle it properly.\u003c/p\u003e\n\u003cp\u003eThe headline: \u003cstrong\u003efor speed, reliability and automation, Usenet genuinely wins.\u003c/strong\u003e For \u0026ldquo;free and no central infrastructure,\u0026rdquo; torrents win. Here\u0026rsquo;s the full breakdown so you can decide on your own use case.\u003c/p\u003e","title":"Usenet vs Torrents: Which Is Actually Better in 2026?"},{"content":"Usenet is a decentralised, worldwide network for posting and retrieving messages and files that predates the web itself. It sounds ancient — it is ancient, roughly as old as email — but in 2026 it\u0026rsquo;s still one of the fastest and most reliable distribution networks in existence. It just works differently to anything you grew up with on the modern internet.\nThis is the plain-English version. No marketing, no scare stories, just how the thing actually works — including the two concepts that make it genuinely different from the modern web: retention and PAR2 repair.\nThe 30-Second Version Usenet is a network of servers that store and exchange articles (chunks of data) on newsgroups (named topic areas). When you use Usenet you\u0026rsquo;re downloading those articles from a provider\u0026rsquo;s server, then your newsreader reassembles them into the files you wanted. For binary files, a small pointer file called an NZB tells your reader exactly which articles to fetch.\nThat\u0026rsquo;s the whole system. Everything else — providers, retention, indexers — is detail on top of that.\nThe Core Concepts, One By One Newsgroups Newsgroups are named discussion/publication areas, organised hierarchically. Text groups look like alt.tv.serendipity or uk.rec.sheds. Binary groups are where people post files, and they\u0026rsquo;re organised by category. You subscribe to a group in your newsreader and it lists the articles available.\nArticles Every post on Usenet is broken into articles — discrete chunks, each with its own unique message ID. A large binary file becomes hundreds or thousands of articles, plus optional PAR2 repair files that let your reader reconstruct missing chunks. Your newsreader pulls the articles, checks the PAR2, and reassembles the original file.\nProviders and retention You don\u0026rsquo;t connect to \u0026ldquo;the internet\u0026rdquo; to get Usenet — you connect to a provider\u0026rsquo;s server over a specific port (usually SSL on port 563). The provider stores articles for a set period called retention. When articles fall outside the retention window, they\u0026rsquo;re deleted. See my Usenet retention explained guide for why big retention numbers can mislead you — and why completion (how complete a file is when you actually pull it) matters more than the headline number of days.\nPAR2 repair — the part most explainers skip This is the quiet engineering magic that keeps binaries usable. Posters add parity files (PAR2) alongside the main binaries — typically 5–10% redundant data. When a download is missing a few articles (from a takedown, a propagation gap, or ageing out of retention), your newsreader uses that parity to reconstruct the missing pieces, the way checksum clues in a crossword let you deduce a missing cell.\nThe catch, and the reason it ties directly into provider choice: PAR2 can only repair up to the parity a release ships with. If a file is missing more than ~10% of its articles, no repair can save it. That\u0026rsquo;s why a provider with high completion beats a provider with a giant retention number — the former keeps you inside working coverage so your finite PAR2 budget is spent on genuine stragglers, not systemic gaps. The full science is in the retention guide — and the hands-on repair walkthrough is in the hands-on repair walkthrough.\nIndexers Because Usenet has no central search, you need an indexer to find binaries — essentially a searchable directory of NZB files. Indexers come in free and paid forms, and they differ enormously in what they index and how fresh they are. I cover the setup dance in the getting-started guide, and the \u0026lsquo;how they work / how to choose\u0026rsquo; detail in Usenet indexers explained.\nNewsreaders and automation A newsreader (like SABnzbd, NZBGet, NZB360, or a desktop client) fetches the articles your NZB references and assembles them into a file. The big improvement of the modern era is automation: tools like Sonarr and Radarr watch for new releases and hand the NZBs to SABnzbd automatically. That\u0026rsquo;s how a lot of people now use Usenet without ever opening a \u0026ldquo;reader\u0026rdquo; app — it just runs in the background on a NAS or a home server.\nHow Downloading Actually Flows Let\u0026rsquo;s trace one download end to end:\nYou find a binary in an indexer and grab its .nzb file — a small XML-style file listing every article and which newsgroups hold it. You open that NZB in SABnzbd (or your reader). SABnzbd connects to your provider\u0026rsquo;s server over SSL, opens many simultaneous connections, and pulls the listed articles. It verifies and repairs with PAR2, then extracts and renames to the final file. That whole pipeline is why Usenet downloads at your line\u0026rsquo;s maximum speed — the provider isn\u0026rsquo;t throttling you the way a torrent swarm or a direct-download host does, and multiple connections saturate your bandwidth.\nWhy People Still Use It in 2026 Usenet\u0026rsquo;s advantages over modern alternatives are concrete:\nSpeed. Server-hosted, so download speed is limited by your connection, not by how many people are seeding. Retention. Major providers keep binaries 15+ years. Old stuff stays findable. Repair. PAR2 parity means a slightly-incomplete download usually still arrives complete. No seeding. You download and leave. You\u0026rsquo;re never asked to give back upload bandwidth. Automation. The whole pipe can run unattended. The honest downsides: it\u0026rsquo;s not free (you pay a provider, and usually an indexer), there\u0026rsquo;s a learning curve, and — let\u0026rsquo;s be real — much of the popular binary traffic exists in a legal grey area. Use it on the right side of the law where you live. That\u0026rsquo;s why the first thing in my setup guide is staying private.\nThe UK Thing Because you\u0026rsquo;re likely reading from the UK: Usenet works well here, but a few UK specifics shape the experience. UK ISPs have historically throttled plaintext Usenet traffic, so SSL on port 563 is effectively mandatory. And heavy sustained downloads can hit Fair Usage Policies on \u0026ldquo;unlimited\u0026rdquo; broadband plans. Neither is a dealbreaker — both are manageable with the right config. The Usenet vs torrents guide has the full UK ISP breakdown.\nUsenet vs the Alternatives The most common comparison is against torrents. Rather than duplicate it here, I\u0026rsquo;ve written the full breakdown: Usenet vs torrents: which is actually better?. Short version: Usenet wins on speed, reliability and automation; torrents win on being free and having no central cost.\nWhere to Go Next Ready to actually start? Follow the 2026 setup guide — it walks you from zero to your first automated download step by step. Pick a provider with the honest roundup: Best Usenet Providers UK 2026. Budget-conscious? The cheapest Usenet providers guide costs out blocks vs unlimited. Want to understand the number every provider brags about — and the repair science behind it? Read Usenet retention explained. Which downloader should you run? SABnzbd vs NZBGet. ","permalink":"https://usenetpirate.co.uk/guides/what-is-usenet/","summary":"\u003cp\u003eUsenet is a decentralised, worldwide network for posting and retrieving messages and files that predates the web itself. It sounds ancient — it \u003cem\u003eis\u003c/em\u003e ancient, roughly as old as email — but in 2026 it\u0026rsquo;s still one of the fastest and most reliable distribution networks in existence. It just works differently to anything you grew up with on the modern internet.\u003c/p\u003e\n\u003cp\u003eThis is the plain-English version. No marketing, no scare stories, just how the thing actually works — including the two concepts that make it genuinely different from the modern web: \u003cstrong\u003eretention\u003c/strong\u003e and \u003cstrong\u003ePAR2 repair\u003c/strong\u003e.\u003c/p\u003e","title":"What Is Usenet and How Does It Work?"}]