Building a Production-Grade Tdarr GPU Transcoding Stack for a Homelab

A lot of homelab media automation starts with a simple goal: make the files smaller and keep Plex happy. That sounds easy until you run real libraries through an automatic transcoder. A basic Tdarr flow can re-encode files that should have been left alone, damage HDR, keep the wrong audio track, strip useful subtitles, leave commentary tracks in place, or finish a transcode without telling Plex, Radarr, or Sonarr that anything changed.

Rights and lawful use: These guides are for organizing, backing up, transcoding, and automating media that you own or are authorized to use. Do not use these workflows to download, store, share, or process copyrighted material unless you have the rights or permission to do so.

This build is a production-minded Tdarr pattern for a two-node GPU homelab. It is designed around controlled automation: decide whether a file actually needs work, protect risky sources, standardize output around HEVC/H.265 10-bit, keep useful English surround audio, remove obvious junk streams, validate the finished file before replacement, and notify Plex plus Radarr/Sonarr after a file changes.

The important part is not just "use the GPU." The important part is building guardrails around the GPU so the automation saves space without silently lowering library quality.

What This Setup Is Trying To Solve

• Convert eligible media to HEVC/H.265 10-bit so files are smaller but still high quality.
• Do not waste GPU time on files that are already good enough.
• Recheck already-HEVC10 files by bitrate and size, not just codec name.
• Keep high-value English audio, preferably surround when available.
• Remove commentary, descriptive audio, non-English audio, and non-English subtitles.
• Keep useful English subtitles, including forced subtitles when present.
• Route HDR, HDR10+, HLG, and Dolby Vision files to review instead of blindly flattening them.
• Validate output before replacing the original file.
• Let Plex know a changed item should be refreshed.
• Let Radarr and Sonarr rescan so MediaInfo, file size, codec, and quality details stay current.
• Limit Tdarr worker counts during peak Plex viewing hours.
• Generate a daily review report so failed or risky jobs do not disappear into the queue.

The download does not include live tokens, passwords, hostnames, private IP addresses, or API keys. The config files use placeholders such as YOUR_PLEX_TOKEN, YOUR_RADARR_API_KEY, YOUR_SONARR_API_KEY, YOUR_PLEX_HOST, and YOUR_TDARR_NODE_ID.

Before You Start: Safe Defaults

• Use this workflow only for media you are allowed to store and transform.
• Keep original media protected until the flow has passed validation on real samples.
• Keep Tdarr cache on local fast storage and final media on the NAS or media volume.
• Back up Tdarr config, flow plugins, helper scripts, and Arr/Plex integration settings before production changes.
• Do not expose Tdarr, Radarr, Sonarr, SABnzbd, or Prowlarr directly to the public internet.

High-Level Architecture

The pattern assumes one Tdarr server and at least one Tdarr node. In my preferred layout, the Tdarr server coordinates the queue and plugin logic, while GPU nodes perform the actual transcode work. Plex, Radarr, Sonarr, and the media storage are treated as separate systems that Tdarr must update after a file is replaced.

1. Tdarr Server: Owns libraries, flows, plugin definitions, file database, queue state, and the UI.
2. Tdarr GPU Nodes: Run the workers. They need access to the same media paths and local cache paths used by the server.
3. Local cache/transcode space: Temporary work should happen on local disk or fast local SSD, not over a slow network share.
4. NAS/media storage: Stores final media. The NAS should not be hammered with temporary transcode writes.
5. Plex: Serves the library and needs item or library refreshes after replacement.
6. Radarr/Sonarr: Track movie/episode metadata and need rescans after Tdarr changes the underlying file.
7. Cron/helper scripts: Adjust worker limits by time of day and produce review reports.

The design separates "decision work" from "heavy work." The flow decides what should happen first. Only then does the GPU spend time encoding. That keeps the system predictable and avoids the classic problem where a transcoder happily burns through thousands of files but leaves you with a mess to audit later.

1. PolicyTdarr Server

   Stores libraries, queues, flows, plugins, job state, and worker limits.

2. Worker APrimary GPU Node

   Runs GPU transcodes with controlled worker count and local cache.

3. Worker BSecondary GPU Node

   Adds capacity but should still respect Plex viewing windows.

4. SharedMedia Paths

   Nodes must see the same media paths or have reliable path mappings.

5. NotifyPlex + Arr APIs

   After replacement, refresh Plex and rescan Radarr/Sonarr so metadata stays accurate.

Library-wide laterTest one file before enabling broad production library processing.

SecretsPlex tokens and Arr API keys belong in private config, not screenshots or downloadable examples.

The Production Flow Order

The best Tdarr flow is not just a pile of plugins. The order matters. A safe production flow should look something like this:

1. File settling check: Ignore files that were created or modified too recently. This avoids grabbing a file while SABnzbd, Radarr, Sonarr, or another process is still writing it.
2. Health check: Confirm the file can be probed and has video/audio metadata.
3. HDR/DV guard: Detect HDR, HDR10+, HLG, BT.2020, or Dolby Vision risk and route those files to review.
4. Codec and bit-depth decision: Decide whether the file is already HEVC 10-bit or needs video work.
5. HEVC10 size policy: If the file is already HEVC 10-bit, check whether it is still oversized before skipping it.
6. Audio/subtitle cleanup: Keep the best English non-commentary audio, keep useful English subtitles, remove commentary and non-English streams.
7. Video encode branch: If needed, encode to HEVC/H.265 10-bit with GPU acceleration.
8. Container and stream mapping: Preserve the correct streams and output to the expected container.
9. Output validation: Confirm the new file still has video, audio, HEVC, 10-bit output, sane size, and sane duration.
10. Replace original: Only replace the original file after validation passes.
11. Plex refresh: Trigger Plex so the changed item is rescanned.
12. Radarr/Sonarr rescan: Trigger the matching Arr app so MediaInfo and quality tracking update.
13. Review reporting: Leave any risky or failed items visible for daily review.

That order is what makes the build feel reliable. The dangerous cases are filtered early, the expensive GPU work happens only when justified, and replacement happens only after the new output passes basic sanity checks.

1. 1. SettleFile Age Check

   Skip files that were created or modified too recently so partial writes are not processed.

2. 2. ProbeMedia Health

   Confirm the file has readable video/audio metadata before policy decisions.

3. 3. GuardHDR / DV Review

   Route risky HDR, HDR10+, HLG, or Dolby Vision sources to review instead of flattening them blindly.

4. 4. DecideHEVC10 Size Policy

   Skip files that are already good enough; re-encode HEVC10 only if oversized by policy.

5. 5. CleanAudio + Subtitles

   Keep useful English audio/subtitles, remove commentary and unwanted streams.

6. 6. EncodeGPU Transcode

   Encode eligible files to HEVC/H.265 10-bit with controlled worker limits.

7. 7. ValidateReplace or Review

   Check duration, streams, codec, bit depth, size ratio, and playback signals before replacement.

8. 8. NotifyPlex + Arr Refresh

   Refresh Plex and rescan Radarr/Sonarr only after a successful replacement.

Human review queueFailed, risky, or unexpected jobs should be visible for review, not silently deleted.

Rights gateUse these workflows only for media you own or are authorized to store, download, organize, or transcode.

Movie Flow vs TV Flow

I prefer separate flows for movies and TV even when the rules are similar. Movies tend to have larger files, more audio tracks, more subtitle options, more HDR sources, and more remux-style releases. TV libraries usually have more files, shorter durations, more inconsistent release sources, and a bigger chance of running into bulk queue behavior.

Area	Movie Flow	TV Flow
Primary goal	High-quality space savings without wrecking premium sources	Consistent format and predictable playback across many episodes
HDR handling	More conservative; review risky HDR/DV sources	Still conservative, but most SDR episodes can move through normally
Audio	Prefer best English surround track when present	Prefer English track; surround if available, stereo when that is all that exists
Size policy	More important because individual files can be very large	Still useful, especially for oversized 1080p episodes
Queue strategy	Lower parallelism is usually fine	More files, so pacing and reporting matter more

The logic can share plugins, but the thresholds and queue behavior do not have to be identical. A 4K movie and a 22-minute TV episode should not be treated like the same operational object.

HEVC/H.265 10-Bit Strategy

The target format is HEVC/H.265 10-bit. I like 10-bit even for SDR because it generally handles gradients better, gives the encoder more room, and is widely supported by modern Plex clients. The tradeoff is compatibility with very old clients, but in a modern homelab/Plex environment, HEVC Main10 is usually the better long-term library format.

The key mistake is assuming every HEVC 10-bit file should be skipped. Some already-HEVC files are bloated. They may be high-bitrate remuxes, weak encodes, or files with extra audio/subtitle baggage. That is why the size policy exists.

The included codexHevcSizePolicy plugin checks resolution, duration, file size, and calculated bitrate. If a file is already HEVC 10-bit but exceeds the target bitrate plus headroom, it marks the file for re-encode instead of skipping it blindly.

Resolution	Default target bitrate	Why it exists
480p	2500 Kbps	Avoid oversized legacy content.
720p	4500 Kbps	Keep episodes compact without obvious quality loss.
1080p	8500 Kbps	Good general target for movies and TV.
1440p	14000 Kbps	Headroom for uncommon higher-resolution media.
2160p	28000 Kbps	Conservative enough for 4K while still catching huge files.

The default headroom is 10 percent, and files smaller than 1 GB are ignored by the size policy. That prevents the system from wasting effort on small files where the savings would not be worth the churn.

HEVC10 decision example:

1080p movie
Actual bitrate: 14,500 Kbps
Target bitrate: 8,500 Kbps
Headroom: 10%
Allowed bitrate: 9,350 Kbps

Result: re-encode, because 14,500 Kbps is above the allowed target.

HDR and Dolby Vision Guardrails

HDR is where automated transcoding can get ugly. If you feed HDR10, HDR10+, HLG, BT.2020, or Dolby Vision into a normal SDR flow without careful tone mapping and metadata handling, you can end up with washed-out colors, missing dynamic metadata, broken playback, or a technically valid file that simply looks wrong.

The included codexHdrGuard plugin looks for signals such as PQ/SMPTE 2084 transfer, HLG transfer, BT.2020 color, Dolby Vision metadata, HDR10+ metadata, mastering display data, MaxCLL, and MaxFALL. When it finds those signals, the safe default is to route the item to review instead of sending it through the normal SDR HEVC flow.

• SDR file: Continue through the normal flow.
• HDR10 file: Route to review unless you have a dedicated HDR-preserving workflow.
• Dolby Vision file: Route to review. Do not casually strip or flatten DV metadata.
• Unknown HDR metadata: Route to review. Unknown is not the same as safe.

Long term, a separate HDR-preserving flow can be added. I would still keep it separate from the everyday SDR workflow. HDR deserves its own testing, preview samples, and acceptance criteria.

Audio and Subtitle Cleanup

Audio is one of the easiest places to waste space. A movie can carry multiple languages, multiple commentary tracks, descriptive audio, stereo duplicates, and subtitle tracks that nobody in the household uses. Cleaning that up across a library can save a surprising amount of space, especially when paired with video compression.

The included codexCleanEnglishStreams plugin is intentionally opinionated. It keeps one best English non-commentary audio stream, prefers the stream with the most channels, keeps English subtitles, and removes non-English or commentary-style streams. Commentary detection looks for terms like commentary, director, producer, descriptive, audio description, visual impaired, hearing impaired, and isolated score.

Stream type	Behavior
English 7.1/5.1 main audio	Preferred when available.
English stereo main audio	Kept when no better English surround track exists.
Director commentary	Removed.
Audio description/descriptive audio	Removed unless you intentionally change the rule.
Non-English audio	Removed.
English subtitles	Kept.
Forced English subtitles	Kept.
Non-English subtitles	Removed.

For surround audio, the default target is E-AC-3 at 640 Kbps, 6 channels, 48 kHz. For stereo-only sources, the target is AAC stereo at 192 Kbps, 48 kHz. That gives a practical balance: keep surround where it matters, but do not carry a pile of duplicate or unused tracks.

Output Validation Before Replacement

The most important safety rule is simple: never replace the original just because FFmpeg produced a file. A file can exist and still be wrong. It can be missing audio, missing video, too short, too small, the wrong codec, the wrong bit depth, or the result of accidentally running an HDR source through the wrong branch.

The included codexOutputValidator plugin checks for:

• At least one video stream.
• At least one audio stream.
• HEVC output when HEVC is required.
• 10-bit/Main10 output when 10-bit is required.
• Output duration within the expected ratio of the original.
• Output file size above a minimum sane ratio of the original.
• Original HDR/DV indicators that should not be auto-replaced by the SDR flow.

The default duration window is 98 percent to 102 percent of the original duration. The default minimum size ratio is 8 percent. That is not a quality guarantee, but it catches many obvious failures before they become permanent replacements.

Plex and Arr Refreshes

After Tdarr replaces a file, the media server and the management apps need to know. Plex may keep stale stream and bitrate data until it rescans. Radarr and Sonarr may still think the old file exists with the old size, codec, quality profile, or MediaInfo values.

The bundle includes local flow plugins for Plex refresh and Arr refresh. The Plex refresh plugin maps changed paths to Plex library sections. The Arr refresh plugin can call Radarr and Sonarr so they rescan matching movies or episodes after the file changes.

{
  "plexBaseUrl": "http://YOUR_PLEX_HOST:32400",
  "plexToken": "YOUR_PLEX_TOKEN",
  "timeoutMs": 30000,
  "libraries": [
    {
      "title": "Movies",
      "sectionId": "1",
      "pathPrefix": "/mnt/media/Movies"
    },
    {
      "title": "TV",
      "sectionId": "2",
      "pathPrefix": "/mnt/media/TV"
    }
  ]
}

{
  "instances": [
    {
      "name": "Radarr",
      "type": "radarr",
      "baseUrl": "http://YOUR_RADARR_HOST:7878",
      "apiKey": "YOUR_RADARR_API_KEY",
      "timeoutMs": 60000,
      "pathPrefixes": ["/mnt/media/Movies"]
    },
    {
      "name": "Sonarr",
      "type": "sonarr",
      "baseUrl": "http://YOUR_SONARR_HOST:8989",
      "apiKey": "YOUR_SONARR_API_KEY",
      "timeoutMs": 60000,
      "pathPrefixes": ["/mnt/media/TV"]
    }
  ]
}

This is also why Radarr and Sonarr quality strategy matters. If those apps are configured to keep upgrading until a preferred HEVC 10-bit release is found, you do not want Tdarr to create confusion. After Tdarr changes a file, Radarr/Sonarr should rescan and update MediaInfo so future upgrade decisions are based on the file that actually exists, not stale release-title assumptions.

Worker Scheduling and GPU Sharing

A GPU that is perfect for Tdarr can also be needed by Plex. If Tdarr consumes every available encode session during prime viewing time, users can feel it. The better pattern is to let Tdarr work harder off-peak and back down during peak Plex hours.

The included tdarr_worker_schedule.py helper adjusts Tdarr GPU worker limits by time of day. The example uses more GPU workers off-peak and fewer during peak hours. It also supports a disable-file, so you can temporarily pause the scheduler without editing cron.

CRON_TZ=America/Chicago
TDARR_API_BASE=http://127.0.0.1:8266/api/v2

# /etc/tdarr-worker-schedule.env
TDARR_OFFPEAK_TARGETS='{
  "YOUR_PRIMARY_TDARR_NODE_ID": 2,
  "YOUR_SECONDARY_TDARR_NODE_ID": 1
}'

TDARR_PEAK_TARGETS='{
  "YOUR_PRIMARY_TDARR_NODE_ID": 1,
  "YOUR_SECONDARY_TDARR_NODE_ID": 0
}'

TDARR_PEAK_START=18:00
TDARR_PEAK_END=23:00

# /home/YOUR_USER/bin/run_tdarr_worker_schedule.sh
#!/usr/bin/env bash
source /etc/tdarr-worker-schedule.env

exec /usr/bin/python3 /home/YOUR_USER/bin/tdarr_worker_schedule.py \
  >> /home/YOUR_USER/logs/tdarr_worker_schedule.log \
  2>&1

# crontab
CRON_TZ=America/Chicago
*/5 * * * * /home/YOUR_USER/bin/run_tdarr_worker_schedule.sh

The exact counts depend on your GPU, Plex load, and tolerance for queue speed. For a balanced two-node setup, a conservative starting point is two GPU workers on the stronger node and one on the secondary node off-peak, then one worker on the primary node and zero on the secondary node during peak viewing hours. That leaves capacity for Plex while still letting Tdarr make progress.

Cache and Storage Placement

Do not put heavy transcode cache work on a NAS share unless you have a very specific reason. Network shares are great for final media storage. They are usually not the best place for temporary encode output, partial files, or high-churn work directories.

• Good: Tdarr cache on local SSD/NVMe.
• Good: SABnzbd incomplete downloads on local disk, completed downloads to the final import path.
• Good: Final Plex media on NAS-backed storage.
• Risky: Tdarr temporary output over CIFS/NFS while multiple workers are active.
• Risky: Plex transcode temp and Tdarr cache fighting on the same slow disk.

The practical rule is simple: temporary work should be local and fast; final media can live on shared storage. That reduces network chatter, lowers the chance of partial-write problems, and makes GPU workers feel much smoother.

New File Settling

Tdarr should not immediately process a file that just appeared. Radarr, Sonarr, SABnzbd, or another process may still be moving, unpacking, renaming, importing, or setting permissions. A settling delay prevents Tdarr from grabbing a file while another app still owns it.

A practical default is 10 to 20 minutes. I like 15 minutes for normal media libraries. If your downloads are large, your NAS is slow, or imports happen across mounts, increase it.

Daily Review Report

Automation should still have a cockpit. The included tdarr_review_report.py script reads Tdarr state and writes a daily report with counts for items that need attention. It does not clear the queue and it does not auto-delete anything. Its job is visibility.

# /home/YOUR_USER/bin/run_tdarr_review_report.sh
#!/usr/bin/env bash

exec /usr/bin/python3 /home/YOUR_USER/bin/tdarr_review_report.py \
  >> /home/YOUR_USER/logs/tdarr_review_report.log \
  2>&1

# crontab
15 8 * * * /home/YOUR_USER/bin/run_tdarr_review_report.sh

That daily report is where I want HDR review items, output validation failures, missing English audio, and failed jobs to show up. If a file needs a human decision, it should be obvious.

Testing Before Full Production

Do not point a new flow at the whole library on day one. Test it like a change window.

1. Pick one non-critical SDR movie that is not already HEVC 10-bit.
2. Run the flow and compare original size, output size, duration, video codec, bit depth, audio streams, and subtitle streams.
3. Confirm Plex sees the updated file after the refresh.
4. Confirm Radarr or Sonarr updates MediaInfo after rescan.
5. Test one already-HEVC10 file that is oversized and should be re-encoded.
6. Test one already-HEVC10 file that is within target and should be skipped.
7. Test one file with commentary tracks and confirm they are removed.
8. Test one HDR or Dolby Vision file and confirm it routes to review instead of replacing automatically.
9. Only then enable folder watch and broader library processing.

The goal is to prove every branch: encode, skip, re-encode oversized HEVC10, stream cleanup, HDR review, output validation failure, Plex refresh, and Arr rescan. If you only test the happy path, you have not tested the system.

Install Options: Native Ubuntu or Docker

Tdarr can run directly on Ubuntu or in Docker. Docker is easier to rebuild because the server, node, config, cache, and media mappings are visible in one Compose file. Native Ubuntu is fine when you already manage services with systemd, but document the service user, paths, and plugin locations.

Docker Compose Pattern

Use the same host path mapping on the server and every node. If the server sees a file as /data/media/movies/Movie.mkv, the node must see the same file at the same path. That one rule prevents a lot of Tdarr node failures.

services:
  tdarr:
    image: ghcr.io/haveagitgat/tdarr:latest
    container_name: tdarr
    environment:
      - TZ=America/Chicago
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=002
    volumes:
      - /opt/media-stack/tdarr/server:/app/server
      - /opt/media-stack/tdarr/configs:/app/configs
      - /data:/data
      - /data/cache/tdarr:/temp
    ports:
      - "127.0.0.1:8265:8265"
      - "8266:8266"
    restart: unless-stopped

  tdarr-node:
    image: ghcr.io/haveagitgat/tdarr_node:latest
    container_name: tdarr-node
    gpus: all
    environment:
      - TZ=America/Chicago
      - PUID=${PUID}
      - PGID=${PGID}
      - UMASK=002
      - nodeName=tdarr-node-gpu
      - serverIP=tdarr
      - serverPort=8266
    volumes:
      - /opt/media-stack/tdarr/configs:/app/configs
      - /data:/data
      - /data/cache/tdarr:/temp
    restart: unless-stopped

Production Docker note: The examples use readable image names for clarity. After your test install is stable, pin each image to a tested release tag or digest, back up the config folder, then update intentionally instead of letting surprise container updates change multiple services at once.

The UI port is localhost-only in this example. The server port must be reachable by remote Tdarr nodes if you run them on other hosts, so use LAN firewall rules or a private network. For GPU Docker nodes, install and test the NVIDIA Container Toolkit before blaming Tdarr.

Native Ubuntu Pattern

sudo apt update
sudo apt install -y curl jq mediainfo ffmpeg acl
sudo groupadd -f media

sudo install -d -o root -g media -m 2775 \
  /opt/Tdarr \
  /data/cache/tdarr

sudo chgrp -R media \
  /data/media \
  /data/cache/tdarr

sudo chmod -R g+rwX \
  /data/media \
  /data/cache/tdarr

# Install the current Tdarr server/node release from the official Tdarr source.
# Run the server and node as service accounts in the media group.
# Document the release, install path, service user, and cache path.

Basic Install Pattern

The bundle includes local flow plugins and helper scripts. The plugin folder belongs on the Tdarr server and, depending on your deployment, may also need to be available to each Tdarr node.

FLOW_PLUGIN_SUBDIR="FlowPlugins/LocalFlowPlugins"
server_plugins="/opt/Tdarr/server/Tdarr/Plugins/$FLOW_PLUGIN_SUBDIR"
node_plugins="/opt/Tdarr/Tdarr_Node/assets/app/plugins/$FLOW_PLUGIN_SUBDIR"

sudo mkdir -p \
  "$server_plugins" \
  "$node_plugins"

sudo cp -a plugins/codex "$server_plugins/"
sudo cp -a plugins/codex "$node_plugins/"

Install the helper scripts somewhere predictable, then create real config files from the templates.

install -d -m 755 \
  "$HOME/bin" \
  "$HOME/logs"

install -m 755 \
  bin/tdarr_worker_schedule.py \
  "$HOME/bin/"

install -m 755 \
  bin/tdarr_review_report.py \
  "$HOME/bin/"

sudo install -d -m 750 /opt/Tdarr/config

sudo cp \
  config-templates/plex-refresh.example.json \
  /opt/Tdarr/config/plex-refresh.json

sudo cp \
  config-templates/arr-refresh.example.json \
  /opt/Tdarr/config/arr-refresh.json

sudo chmod 640 /opt/Tdarr/config/*.json

Then edit the config files with your own Plex token, Radarr key, Sonarr key, URLs, library section IDs, and path prefixes. Do not paste real keys into blog posts, screenshots, GitHub issues, or shared config examples.

Rollback and Quarantine Plan

A world-class transcoding flow includes a way out. Before you allow automatic replacement, decide where failed outputs, risky HDR items, and questionable results go. A simple quarantine folder plus daily report is enough for many homelabs.

sudo install -d -o tdarr -g media -m 2775 \
  /data/quarantine/tdarr \
  /data/cache/tdarr

# Production rule of thumb:
#
# 1. Transcode into cache.
# 2. Validate duration, codec, bit depth, audio, subtitles, and size.
# 3. Refresh Plex and rescan Radarr/Sonarr after replacement.
# 4. Move failures or HDR/DV review items to a visible report.

If a validation step fails, keep the original. Do not teach the flow to delete originals just because a transcode command exited successfully. FFmpeg success is not the same thing as an acceptable library file.

Operational Runbook

• Before updates: Pause library processing, snapshot or back up Tdarr config, and make sure no jobs are mid-replace.
• Before enabling a new flow: Run a small manual test library.
• During production: Watch GPU utilization, Plex transcode sessions, Tdarr error states, and disk free space.
• Daily: Review the Tdarr report and manually inspect HDR/DV review items.
• Weekly: Check whether Radarr/Sonarr are still seeing upgraded files correctly.
• After driver or kernel changes: Verify NVIDIA, NVENC, Tdarr nodes, and any required NVIDIA patching before restarting full processing.

What I Would Not Automate Blindly

Some things should stay conservative unless you have tested them deeply:

• Automatic HDR to SDR tone mapping for the whole library.
• Automatic Dolby Vision conversion or metadata stripping.
• Deleting all alternate audio without checking household language needs.
• Replacing originals without duration and stream validation.
• Running every GPU worker at maximum while Plex users are active.
• Letting Tdarr process files that are still being imported.

Final Thoughts

This is the difference between a casual transcoding queue and a production-minded homelab workflow. The value is not just the HEVC output. The value is the system around it: file settling, HDR review, HEVC10 size policy, English stream cleanup, output validation, Plex refresh, Radarr/Sonarr rescan, scheduled worker limits, and daily visibility.

Once those pieces are in place, Tdarr becomes less of a risky bulk converter and more of a controlled media maintenance pipeline. That is the version I trust with real libraries.