Introduction

When you first set up Tdarr to optimize a massive media library, the instinct is to throw every available resource at the problem. I found myself looking at my node settings and wondering: "If one GPU worker is fast, wouldn't two be faster? Should I add CPU workers to help the load?"

After some testing and deep-diving into how Intel QuickSync (QSV) actually works, I discovered that "maxing out" your system isn't about the number of workers, but about how you utilize your hardware's specific engines.

🔍 What I Discovered

1. The "Single Engine" Reality of QSV

I initially thought adding more GPU workers would distribute the load. However, Intel QuickSync isn't like a CPU with multiple cores; it is a dedicated hardware ASIC (Application-Specific Integrated Circuit) designed for one purpose: encoding/decoding video.

While some Intel chips can handle multiple simultaneous streams, they all share the same hardware bandwidth. Adding a second worker doesn't add more "power"—it just forces the hardware to split its existing power between two files. This often leads to:

  • Diminishing Returns: No actual increase in total FPS.

  • Instability: Increased risk of VRAM exhaustion and driver hangs/crashes.

2. GPU vs. CPU: Speed vs. Quality

I questioned whether a CPU worker could "assist" the GPU. The reality is that they operate in two entirely different worlds:

  • GPU (Hardware Encoding): Blazing fast (I was hitting 109 FPS) and energy-efficient.

  • CPU (Software Encoding): Much slower, but generally offers slightly better compression (smaller files for the same quality).

Trying to run both simultaneously usually results in the CPU stealing resources from the GPU, actually slowing down the overall process.

3. Decoding the "Compression Percentages"

I noticed two percentages in Tdarr: C and T. Understanding these is key to knowing if your plugins are actually working:

  • C (Container): The total file size reduction (Video + Audio + Metadata).

  • T (Track): The specific reduction of the video stream itself.

If these numbers are over 100%, your "compressed" file is actually growing, signaling that you need to adjust your quality settings or stop transcoding that specific file.

🛠️ What I Implemented (The "Golden Setup")

Based on these discoveries, I moved away from "maxing out" and toward "optimizing." My current strategy:

  • Single GPU Worker: I stuck with one QSV worker to maintain a stable, high-speed throughput (100+ FPS) without risking system crashes.

  • Zero CPU Workers: I disabled CPU transcoding to avoid the "bottleneck effect" and keep my system responsive for other tasks.

  • Monitoring over Guessing: Instead of adding workers, I now monitor the FPS and Compression % to ensure the hardware is saturated and the files are actually shrinking.

đź’ˇ Pro-Tips for Other Tdarr Users

If you are looking to optimize your own library, keep these three rules in mind:

  1. 1.

    Don't Chase Worker Numbers: If your GPU is already hitting high FPS, adding more workers will likely only increase your crash rate, not your speed.

  2. 2.

    Check Your Generation: QuickSync performance is tied more to the generation of your Intel CPU (e.g., 11th Gen vs 13th Gen) than the model number (i3 vs i7).

  3. 3.

    Watch the "T" Percentage: If your Video Track (T) isn't dropping significantly, your plugin settings are too conservative. Adjust your CRF or Bitrate settings to actually save disk space.

Final Verdict: Let the GPU crank away. Hardware acceleration is a cheat code for media management—don't break it by trying to "help" it with CPU workers.

I’ll post more on what my TDarr flow looks like as I let it churn and get an idea of space saved.