I don't know much about quicksync but it's very likely that you're just missing something on debian to have it working. I believe the hardware in that mini pc (particularly the 32gb of ram, that's practically gold) is more than capable of running all the services you listed.
this post was submitted on 17 Jun 2026
28 points (96.7% liked)
Selfhosted
60021 readers
874 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam.
-
Posts here are to be centered around self-hosting. Please ensure it is clear in your post how it relates to self-hosting.
-
Don't duplicate the full text of your blog or git here. Just post the link for folks to click.
-
Submission headline should match the article title.
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 3 years ago
MODERATORS
Figure I can work out stuff like quick sync easy enough. Main concern was spending $100 or so on the USB enclosure and hours setting it up just to have to go back to the more powerful PC.
If you’re going to run the drives as individual drives in the enclosure, you should be fine but if you set them up as a RAID array, USB won’t work well. The connection is too unreliable and will cause issues. I’ve tried with a 10-bay USB-C enclosure using unRAID, Fedora, and Debian. I tried multiple cables. It just kept dropping the connection during large transfers.
Good to know. Storage space is expensive though and anything that's using the big drives can be downloaded again if needed. So plan was to use online backup for the stuff I can't lose like immich photos, actual budget etc and if a media drive crashes, I'll just redownload.
I wonder if it was just a shitty chipset, or if it was overheating.
Nah, I looked into it and USB is just super unreliable for any sort of array. The drives all worked just fine if I ran them as individual drives.
Yeah but like... where is the weak link? Is there some deficiency in the protocol itself? Or the implementation in the chipset on one or both sides? Or bandwidth, or overheating?
I don't run the 'arr stack, but for comparison, one of my servers is a Optiplex 7020 SFF / i7-4790 / 32GB RAM. It's running around 45 containers now with ease from automatons with n8n to streaming audio with Navidrome. In fact, it spends most of it's life in an idle state with load averages looking like .20/.27/.32. I don't do any transcoding tho, so I can't speak to that as far as resources. I see others have made suggestions in that dept. As far as the 4 bay USB HDD, you're going to need some storage space at some point or another so it's not like it would be wasted effort.
I'd call it decidedly overpowered for what you need - though I put my storage elsewhere, I'm using an 8th gen intel i5 for that and more.
With QSV, you can handle 2 transcodes simultaneously easily. I mentioned recently on mine that I had 6 simultaneous, of those were 4 transcodes and 2 direct streams, and utilization was barely more than where it idles at (while running everything else).
Did you pass the igpu to container?
Yes, but probably not correctly. That's pretty much when I called it a day and haven't tried to use it since.
Probably not helping. All i did was passing /dev/dri as device when i setup my jellyfin container . I
Did you check the render group matches? https://jellyfin.org/docs/general/post-install/transcoding/hardware-acceleration/intel#configure-with-linux-virtualization
The most useful part of those articles is the ffmpeg command you can run inside the container to test it.
I didn't. Its docker container running on unraid fwiw.
I don't think I did as that doesn't sound familiar. Something to look into. Thanks.
I run Jellyfin with hardware transcoding via QuickSync (through VAAPI) on a 10th-gen i3 NUC, 16gb RAM, and it seems to handle it comfortably. Your hardware should definitely be capable.
This is Proxmox with Jellyfin as native install in an LXC so it's not exactly identical to your current setup, but what I found was that passing the device through is only half of it - the host also needs the Intel driver in place for QuickSync to actually work. Try running vainfo on the host to check, if it doesn't list H.264/Hevc encode, the GPU block isn't available yet and Jellyfin will fall back to software - this is probably what you're seeing with the maxed out CPU.
After THAT, make sure Jellyfin has permission to use the passed-through device.
I was just going through this last week, migrating JF off my NAS, and it took some fiddling to get it working.
@Itsamelemmy
You need to pass your gpu to the container.
Check the jellyfin docs for your specific gpu, but por my amd it's some like this
devices: - /dev/dri/renderD128:/dev/dri/renderD128
Olso check on jellyfin docs for needed pkgs for hard accel to work on the host
I remember putting something like that into the compose file, but didn't spend a lot of time trying to figure out why it didn't work.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| LXC | Linux Containers |
| NAS | Network-Attached Storage |
| NUC | Next Unit of Computing brand of Intel small computers |
| RAID | Redundant Array of Independent Disks for mass storage |
[Thread #16 for this comm, first seen 18th Jun 2026, 00:10] [FAQ] [Full list] [Contact] [Source code]