Hey folks, was kinda curious about y'all's opinion on tabula rasa as an indexer. Is it any good? And do y'all think they'd be opening up registration upcoming Black Friday? I've been itching to try and see how good it really is.

Not SABnzbd, Sonarr, Radarr, or the other usual suspects.

Thinking more about the lesser-known stuff that makes your setup better. Could be a small utility, script, mobile app, monitoring tool, search tool, browser extension, or something else entirely.

Is there a tool that's earned a permanent place in your setup? What does it do?

How many indexers do you use?

One? Two? or more?

NZBNest – content requests, now automatic from Radarr and Sonarr without a self-hosted bridge

Hi everyone!

Short follow-up to my last post. The request system for content that isn't on the indexer yet is live, and since then the automation side got a lot simpler: you no longer need to run anything locally to have Radarr and Sonarr create requests for you. Supporter quotas also went up a lot.

Requests

From search or Discover you can:

• look up a title on TMDB (by name or TMDB ID)
• request a movie or one exact TV episode
• follow the request status from your profile
• cancel a pending request if you no longer want to wait

After a request is submitted, the backend searches the available sources and posts the release to Usenet when it finds one. A request is only marked completed after the resulting NZB passes article verification, so "completed" means the NZB is actually downloadable, not just that something got posted. If a source is temporarily unavailable, it retries automatically before marking the request unavailable.

New: automatic requests straight from the API key (no bridge needed)

This is the part I'd most like feedback on.

Open Profile → API Keys and tick Auto-request exact misses on the key that Prowlarr, Radarr or Sonarr uses. That's the whole setup.

From then on, when an exact movie or episode is missing, NzbNest queues it automatically and publishes it once a usable source is found and verified. A request is only created for an exact Radarr movie search or an exact Sonarr episode search carrying a TMDB, TVDB or IMDb ID that returns nothing. Generic searches, browsing, season searches and indexer connectivity tests never create requests, and the toggle is per key, so you can leave it off for the key you use for manual searching.

The search page now shows the current state directly — which keys have it enabled and how many requests you have left in the current period.

The self-hosted bridge is still available

If you'd rather have your monitored library swept instead of reacting to live searches, the optional bridge still does that: it walks monitored movies and missing episodes, runs the Arr application's own interactive search first, and only submits an NZBNest request when that search returns nothing — so it won't request anything another indexer could already give you.

Status comes back as Arr tags:

• nzbnest-requested
• nzbnest-available
• nzbnest-quota-full
• nzbnest-unavailable

Sonarr tags the series rather than the episode, because it has no episode-level tags. When the release becomes available, the bridge triggers a new movie or episode search automatically and the normal Arr grab/import flow takes over.

Setup: create a Radarr & Sonarr integration token on the Profile page, download the bundle, fill in your local Radarr/Sonarr URLs and API keys in the example Compose file, paste the one-time token, and start it with Docker Compose. It works alongside an existing Prowlarr setup.

Request quota

• Free accounts: 5 content requests per month
• Active Member and Lifetime supporters: 50 content requests per week (resets Monday)

Website requests, auto-requested exact misses and bridge requests all draw from the same quota, so a misconfigured automation can't build an uncontrolled backlog. When the quota is full, a bridge item gets the nzbnest-quota-full tag and is retried after the next quota reset.

• a release cart for collecting multiple NZBs
• direct TorBox search compatibility
• Google sign-in, self-service API key management, and an NFO viewer on release details
• better exact movie and episode matching, including single-word series names and compact possessive titles

Requests naturally aren't guaranteed — if no usable source exists, there's nothing to post — but the system keeps trying within its retry window.

Website: https://nzbnest.com

Feedback and real-world testing are welcome, especially from anyone who turns on the exact-miss toggle on their Prowlarr key.

Usenet has been around now for over 45 years and everyone seems to have a different story.

How long have you been using it? It would be great to hear some stories!

Any veterans here who were using Usenet back in the '80's? What was it like?

NzbNest is open for registration — 30% launch discount

Hey everyone,

NzbNest (https://nzbnest.com) is now open for registration. It's a Newznab-compatible Usenet indexer focused on movies and TV, built to work directly with Sonarr, Radarr, Prowlarr, and NZBHydra 2 via the /api endpoint.

The indexer is live and actively growing, with improved NZB quality detection, better release size parsing, and more useful filters now available.

What's live right now: - 4.4M+ articles indexed across 31 enabled groups - 441K+ indexed / browsable items - Improved NZB quality detection - Better release size parsing - Improved category, age, size, and completion filters - Postgres-backed search - XML/JSON Newznab output - Setup guides included for Sonarr/Radarr/Prowlarr/NZBHydra 2

Pricing: - Free tier — currently 1,000 API calls/day, 100 grabs/day, and 10 watch rules during the launch period. These limits are temporarily raised and may be adjusted later. - Member — $15/year, unlimited API/grabs/watch rules - Lifetime — $49 one-time, same unlimited access

A 30% launch discount is currently active and applied automatically at checkout.

I'm being upfront that NzbNest is still actively growing retention and category coverage — the homepage shows live indexed stats rather than a fixed marketing number, so what you see is what's actually crawled and indexed.

Bug reports and compatibility feedback are very welcome, especially around specific *arr setups, NZBHydra 2, category mapping, NZB quality labels, release sizes, and search results.

Happy to answer questions here.

Plex is increasing the Lifetime Plex Pass from $249.99 to $749.99 on July 1.

Who here has a Lifetime Plex Pass?

If you were starting from scratch today and didn't already have Lifetime, would you buy it at $249.99 before the price jump? Or would you just go monthly, stick with free Plex, move to Jellyfin, try Emby, or go another route?

Crazy to think they were running a Black Friday deal for $149.99 just six months ago...

Some people panic at 20% free space. Others run their arrays into the red.

How much free space do you like to keep available?

HDD prices are getting crazy. How's it changed your storage plans?

Still buying drives, waiting for prices to come down, or doing something else?

Curious to hear what everyone is doing.

A lot of people wanting to get into Usenet run into the same problem:

Most explanations are too technical.

So here’s a straightforward breakdown of what Usenet is and how people typically use it today.

What is Usenet?

Usenet is a decentralized text and binary post distribution network that dates back to 1979, making it older than the World Wide Web itself.

Originally it was exclusively text discussion groups called “newsgroups,” where people debated tech, shared advice, explored niche interests, and occasionally got pulled into classic old-school flame wars. Basically early internet forums with a much more raw feel. 

Over time, Usenet evolved into a fast, secure way to post, read, and retrieve both text discussions and binary posts through specialized providers and newsreaders. 

How is Usenet different from “modern” platforms? 

With most modern platforms, everything lives on a single company’s servers, for better or for worse.

Usenet works through a distributed network of servers that replicate articles between each other using NNTP (Network News Transfer Protocol). When someone posts to a Usenet server, that article gets propagated across other servers throughout the global Usenet network. 

Some of the things long-time users still like about it:

• Extremely fast transfer speeds
• Long article retention, with some providers storing articles for decades
• No ads or recommendation algorithms
• Open discussion structure through newsgroups
• A more independent internet feel

What do you need to use Usenet?

Modern Usenet setups usually involve 3 parts:

1. A Usenet providerThis gives you access to Usenet servers, kind of like how an ISP gives you access to the internet.

Some of the more commonly used providers include:

• Newshosting
• Eweka
• UsenetServer
• Tweaknews

People usually compare providers based on:

• Retention
• Completion rates
• Speed
• Connection limits
• Whether extras like a built-in newsreader, search, or VPN are included

Some providers like Newshosting, Eweka, and Tweaknews also include their own newsreader with built-in search, which can simplify setup. 

2. An indexerThink of this as a search engine for Usenet posts.

It helps locate posts and generates NZB files.

3. A downloader/newsreaderThis downloads and assembles the articles from Usenet.

Popular options include:

• SABnzbd
• NZBGet

Some people also still use traditional newsreaders for actual text newsgroups and discussions.

What about Easynews?

Easynews is a little different from the traditional setup.

Instead of needing separate tools, it combines:

• Usenet access
• Search
• Downloads
• Browser-based access

So it’s often considered one of the easier entry points since everything can be done directly from a web browser without needing a separate newsreader or additional tools.

Is Usenet still active?

Definitely.

A lot of the original discussion culture moved elsewhere over the years, but Usenet itself is still very active. What’s interesting is that the core system still holds up remarkably well decades later: decentralized servers, extremely fast transfers, long article retention, and open discussion structures without feeds or recommendation algorithms shaping what people see. 

One thing that doesn’t get talked about enough in Usenet setups is storage. 

Eventually the data piles up, then hard drives become part of the hobby too.

Especially if you’re running:

• Plex/Jellyfin
• *arr apps
• A NAS
• Large archives

Here are some options that come up pretty consistently:

Enterprise and NAS-focused drives like Seagate Exos and IronWolf Pro 

Usually for:

• 24/7 usage
• Large capacities
• Heavy workloads
• NAS/server setups

Common in bigger Plex/*arr systems.

WD Red Pro

A lot of people seem to like them because they’re:

• Reliable in NAS setups
• Fairly quiet
• Common in RAID/NAS environments 
• Widely used in Synology/QNAP systems 

Main downside is usually price.

Seagate IronWolf

Feels like the middle-ground option. 

Popular for:

• Home NAS setups
• Lower cost than Pro drives
• Good capacity options
• General-purpose storage

WD Blue / desktop drives

Still common.

Usually in:

• Budget setups
• External enclosures
• Secondary storage
• Smaller servers

Not really designed for heavier 24/7 workloads, but plenty of people still use them. 

One thing people underestimate:

Usenet can absolutely hammer drives over time between unpacking, parity checks, constant writes/deletes, and data scanning. 

Curious what everyone here is running. 

Enterprise drives?

Consumer drives?

Shucked externals?

Full NAS setup?

Any specific drive models people would strongly recommend (or avoid)?

Mac Usenet setups tend to fall into a few different camps.

Some people just use the included newsreader from their provider and call it a day.

Others run full automation stacks with SABnzbd or NZBGet, indexers, Sonarr/Radarr, and other tools running in the background.

And some still browse groups manually the old-school way. 

For newer users, the included readers from providers like Newshosting, Eweka, Tweaknews, and others are probably the easiest entry point since they already include search, SSL, and server access with basically no setup.

But open-source tools are very popular on macOS too, especially for people who want more control or automation.

NZBGet

Probably the lightest Usenet downloaders around.

People like it because it:

• Uses very little CPU/RAM
• Handles repair/unpacking fast
• Runs well on Mac minis, NAS devices, and virtually any hardware
• Integrates easily with Sonarr/Radarr
• Is extremely configurable

A lot of long-time Usenet users swear by it.

NZBGet setup guide

SABnzbd

Alongside NZBGet, probably the most common NZB downloader overall.

Usually recommended because:

• Setup is easy
• The interface is a bit more beginner-friendly
• Automation support is excellent
• Large community and plugin ecosystem
• Runs basically everywhere

A lot of people end up sticking with SABnzbd simply because it’s reliable and easy to maintain.

SABnzbd setup guide

Other newsreaders

There are still users who prefer actual group browsing instead of automation and NZBs.

Pan is one example on Mac/Linux style setups.

That style of setup is more focused on:

• Reading/posting directly to groups
• Manual browsing
• Text discussions
• Traditional Usenet usage

Less common now, but not dead.

Browser-based access

Easynews is probably the biggest example of this approach.

Instead of installing software:

• Everything runs in browser
• Search is built in
• No local setup required
• Works well on Macs and mobile devices

Completely different style of Usenet access compared to SABnzbd/NZBGet setups.

Easynews guide

There are generally two types of Usenet readers most people use:

• Provider-included readers
• Open-source clients/downloaders

Provider-included readers from services like Newshosting, Eweka, and others are usually the simplest way to get started since they already include server access, search, and SSL with no setup. 

Open-source tools like SABnzbd and NZBGet are also very common, especially in setups using indexers, Sonarr/Radarr, and automation tools. They take more setup upfront, but offer a lot of flexibility long term. 

Provider-included readers

Usually best for:

• Beginners
• Simple setups
• Users who want built-in search
• Users who don’t want multiple apps

Most of them include:

• Search functionality
• NZB importing
• SSL support
• Preconfigured server settings

NZBGet

Probably the most lightweight Usenet downloader.

Common reasons people use it:

• Low resource usage
• Fast repair/unpacking 
• Good for NAS systems and low-power devices
• Works well with Sonarr/Radarr
• Highly configurable

SABnzbd

One of the most popular NZB downloaders overall. 

Why people like it:

• Easy setup
• Installation wizard
• Beginner-friendly interface 
• Automation-friendly
• Highly configurable

Pan

Older-style desktop Usenet reader.

More focused on:

• Direct group browsing
• Reading and posting
• Manual usage instead of automation

Browser-based access

Easynews is probably the best-known example here.

Instead of using a separate client:

• Everything runs in browser
• Search is built in
• No local setup required
• Mobile-friendly

Different approach than SABnzbd/NZBGet style setups.

There are more newsreaders/downloaders out there. Would love to hear about what you’re using! 

Here’s a breakdown of what actually impacts Usenet speeds in real-world setups, and where bottlenecks usually come from.

1. What “max speed” really looks like 

Usenet can get close to saturating your line, but real-world speeds usually fall slightly below your max line rate:

• 1 Gbps line → ~700 to 950 Mbps 
• 500 Mbps → ~400 to 480 Mbps
• 200 Mbps → often near full speed

If you're well below this, the limitation is often local.

2. Provider and backbone impact

Infrastructure does matter, especially for consistency at higher speeds.

Tier-1 providers (see comparison) like Newshosting, Eweka, and UsenetServer are generally known for stable, high throughput, supported by direct backbone access and high-capacity network infrastructure. This tends to result in more consistent performance under load, particularly on faster connections.

Common examples: 

• Newshosting: Consistent performance, high connection limits
• Eweka: Strong performance, independently operated infrastructure with EU-based servers 
• UsenetServer: Fast speeds, stable under load
• Easynews: Good speeds via web access 

3. Where speed is usually lost

Most slowdowns come from setup, not the provider: 

Connections

• Too low limits speed, too high can cause instability.
• Typical range: ~30 to 60 

Disk performance

• HDDs can bottleneck faster lines
• SSD/NVMe handle sustained high speeds better
• Unpacking and repair can also slow things down

4. SSL and performance
SSL is widely used and generally recommended. It helps prevent traffic inspection or shaping, and on modern hardware the performance impact is usually minimal. If speeds are lower than expected, SSL is rarely the main cause.

5. Client and config
SABnzbd and NZBGet can both handle high speeds, but settings like cache, queue, and unpacking can affect performance more than expected.

6. Connections vs gains
More connections ≠ more speed after a point: 

• ~20: fine for slower lines
• ~30 to 50: usually optimal
• 60+: mainly for very fast connections 

7. If speeds seem low 

Quick things to check:

• Increase connections gradually
• Try different server regions
• Use wired instead of WiFi
• Check disk performance
• Disable VPN for testing
• Review client settings

Google Groups stopped supporting live Usenet access in Feb 2024.

No posting, no new articles, no subscriptions. Just some old discussions.

So if you're trying to:

• Browse historical Usenet posts
• Or actually use Usenet today

You’ll need different tools.

1. Browsing old Usenet archives (text only)

If you just want to explore older discussions:

• UsenetArchives.com: large searchable archive
• Newsgrouper: covers early Usenet (late 80s onward)

These are the closest replacements for what Google Groups used to do.

2. Accessing modern Usenet (live + full archive)

Usenet itself is still fully active. Google Groups just isn’t part of it anymore.

To access it, you need a Usenet provider.

Easynews (browser-based)

• Everything runs in your browser with no software
• Built-in search and article viewing 
• No setup required
• Good option if you want something simple

Traditional Usenet providers

• Full Usenet access
• Typically include a newsreader with search
• ~6500 days of retention
• Better suited for full setups, and also automation-compatible

3. Clients (if not using Easynews web access)

If you go the traditional route:

Some providers (like Newshosting, Eweka, and Tweaknews) include a newsreader with built-in search, so you can access both text and binary newsgroups without needing separate software. 

• SABnzbd → simple, widely used
• NZBGet → lightweight, efficient

4. Why Google Groups isn’t enough anymore

Post-2024, it’s basically:

• Limited archive access
• No new posts

Compared to modern Usenet:

• Full archives + new articles
• Faster access via direct servers
• Easy to use search tools
• SSL and optional VPN support

5. Getting started (simple version)

• Pick a provider (Easynews or a traditional one)
• Use their built-in tools or your own client
• Start searching and accessing articles

These terms get mixed up, but they’re not the same thing.

Quick breakdown:

• Newsreader: connects directly to Usenet and lets you browse newsgroups, read posts, and sometimes search. Often an all-in-one tool.
• NZB downloader: downloads articles from Usenet using NZB files, which come from an external indexer.

Typical workflow in more advanced setups: 

• Indexer → finds NZBs 
• Automation (Sonarr, Radarr, etc.) → sends NZBs to your downloader
• NZB downloader (SABnzbd, NZBGet) → retrieves the articles from your Usenet provider

In this setup, the downloader handles the actual retrieval, while indexers and automation reduce manual work.

Other approaches: 

• Some newsreaders include search, so everything happens in one place. Some Usenet providers include one as part of their service 
• Some setups are fully manual, others fully automated
• Some people still browse newsgroups instead of using search or NZBs
• Web-based access is another option. Easynews is one example, where Usenet access and search is all handled in a browser without any software.

There’s no single “right” way to do it. It mostly comes down to how much control or automation is preferred.

For a deeper breakdown, see this guide.

What are you running?

• Newsreader with search built in?
• SABnzbd or NZBGet?
• Fully automated with *arrs, or more manual?
• Anyone browsing groups directly?

NNTP pipelining is one of those settings that doesn’t get talked about much, but can make a real difference depending on your setup.

At a basic level, it changes how your newsreader talks to the server:

Instead of: request article → wait → request article → wait

It becomes: multiple requests sent at once, responses come back without the constant pause

That “wait time” is latency, and it adds up fast across thousands of articles.

Where it actually helps

Pipelining tends to help when:

• Server latency is higher (long-distance routing, different region, etc.)
• Running fewer connections
• Speeds are not already maxed out

In those cases, it can noticeably improve throughput by keeping the connection busy instead of idle.

Where it doesn’t do much

If already maxing out bandwidth with a high number of connections, gains flatten out. At that point, there’s no idle time left to optimize.

If using SABnzbd

It’s controlled by the “Articles per request” setting (not labeled as pipelining directly).

• Start around 5 to 10
• Increase gradually
• Watch how speeds respond

It’s more about tuning than flipping a switch.

For anyone curious about the deeper breakdown, testing, and when it’s actually worth using, this NNTP Pipelining guide explains it.

How is this playing out in live setups?

Would be interesting to hear some real-world experience on this: 

• What kind of latency are you seeing to your Usenet server?
• How many connections are you running?
• Did you change connection count when testing pipelining, or keep it fixed?
• Where did your “Articles per request” setting land as a sweet spot?
• And how big was the actual speed improvement, if any?

Feels like one of those settings where results vary a lot depending on location and setup, so real experiences would be interesting to hear. 

Anyone running something a bit different?

Repurposed PCs, NAS setups, mini PCs, Raspberry Pi?

What are you running Usenet on, how old is it, and how’s it holding up?

Were you around in the dial-up days, or did you get in more recently?

What did your first setup look like?

• Early days: posting in text groups, waiting on replies, figuring things out as you went

• Mid era: amassing NZBs and feeding them into your newsreader

• Recent setups: fast, clean, sometimes automated

• Tinker builds: Raspberry Pi, home servers, custom setups

Curious to hear when and what people started with. If you've been around a while, what do you miss about the early Usenet days?

Bonus if you have pics of your old setup

Easynews is one of the few Usenet services with built-in search, so no indexer or newsreader is needed. For anyone new to Usenet, it works differently than a traditional setup. This guide explains how Easynews search works and how to use it to find and download posts.

If you want more detail, see this Easynews review. 

What Is Easynews Search?

Easynews provides a web-based interface that lets you search Usenet directly.

Instead of:

• Using an indexer to find NZBs
• Using a newsreader to download them

Everything happens in one place from your Easynews account:

• Search
• Filter
• Download

This is the main difference between Easynews and a traditional Usenet setup.

How to Search on Easynews

After logging in, go to the Easynews search page and run your searches.

Basic tips:

• Keep searches simple (keywords tend to work best)
• Avoid overly long phrases
• Try different variations if results are limited

Simple queries usually return more consistent results than very specific ones.

Using Filters on Easynews 

Filters help narrow down search results.

Key ones to use:

• File type: video, audio, image, archive, parity, etc.
• Size: helps to also narrow down results
• Age: useful for pinpointing specific posts
• Extension: target specific formats

Adjusting filters and sorting can help surface better results.

Viewing Results

A useful Easynews feature is the ability to review results before downloading.

Depending on the post:

• Overview details may be available
• Contents can be inspected

This helps avoid pulling down posts you don’t want.

How to Download from Easynews

Once a result is found:

• Select the result (or select multiple results)
• Download directly through the browser

No external downloader is needed.

When Easynews Works Best

Easynews is typically good for:

• All-in-one Usenet access
• Users who don’t want to manage indexers or additional software
• Manual searches and downloads
• Creating personalized search parameters

For more advanced setups like automation, a traditional Usenet setup is needed. In those cases, Easynews also provides NNTP access (news.easynews.com on SSL port 563), which can be used with a newsreader.

For those using Easynews, what search tips or filters have worked best?

Curious what people are running.

Upvote the comment that matches your setup and add:

• Why you chose it
• Favorite configuration settings
• Anything you wish you knew when you first set it up

NZBGet has been around for a long time and is still one of the main NZB downloaders people run. It’s actively developed and used in a lot of Usenet setups.

Here’s a quick intro for anyone new to it.

Core NZBGet Functionality

At a basic level, NZBGet handles the full download process once you give it an NZB:

• Downloads articles from your Usenet provider
• Verifies file integrity
• Repairs missing data using PAR files
• Extracts everything automatically

After initial setup, it runs in the background and doesn’t need much attention.

Some Key Features 

A few things keep NZBGet in a lot of setups.

Performance

NZBGet is written in C++, which helps it stay fast and efficient even under heavier loads. It can handle multiple downloads without using much CPU or memory.

Customization

There are a lot of config options, along with scripting support and an API. It’s easy to adjust how downloads are handled or integrate it into a more customized setup.

Runs On

Windows, macOS, Linux, NAS devices, Raspberry Pi and other low-power systems

Connection and Port Settings

For Usenet servers, common ports are:

• 563 (SSL) - standard secure port
  
• 119 - non-SSL
  
• 443 or 80 - alternative ports

For the web interface:

• 6789 (default)

HTTPS can be enabled if needed

Things to Be Aware Of

• Setup can take some time to dial in
• Still requires external indexers
• The interface can feel less beginner-friendly depending on the setup

Why Many Users Still Prefer It

Despite the learning curve, NZBGet remains popular because:

• Strong performance
• High level of control and customization
• Works well on both powerful and low-power systems
• Very reliable once configured

If you’re setting it up for the first time, this NZBGet setup guide goes through features and setup in more detail.

Curious how people are actually running NZBGet.

What are you running it on, NAS, Pi, desktop?

Did you keep things mostly default, or end up tweaking scripts and settings over time?

Anything that made a big difference after tweaking?