Build a Jellyfin Media Server: Intel N150 or Arc A310 and Drives

A 4K HDR film plays fine on the living room TV, then stalls on a phone over hotel Wi-Fi. That one conversion, from a 60 Mbps HEVC file to something a phone can stream, is the job a Jellyfin media server has to be built around. Get the transcoding hardware right and the rest of the build is just disks and a case.

Original content from computingforgeeks.com - post 176630

This guide covers two ways to build a Jellyfin media server: a low-power Intel N150 NAS board in a Jonsbo N2, or an Intel Arc A310 added to a desktop you already own. We took the parts from Amazon US listings on October 22, 2026. We ran the software half, Jellyfin 12.2 with Quick Sync and OpenCL tone mapping, on Ubuntu 26.04 in a Proxmox container with an Iris Xe iGPU, and the commands and outputs below come from that run.

Step 1: Pick the transcoding engine first

Jellyfin leans on the Intel media engine for decoding, scaling, tone mapping and encoding, so the GPU decides how many streams the box can serve. The two engines in this guide share the same Linux driver stack, but they are not equal on AV1 or headroom:

Engine	AV1	HEVC 10-bit	Linux kernel floor	Typical box
Intel N150 or N355 iGPU	Decode only	Decode and encode	6.9 or newer	Dedicated NAS board
Intel Arc A310	Decode and encode	Decode and encode	6.2 or newer	Any desktop with a free x16 slot
Iris Xe (our lab)	Decode only	Decode and encode	Already supported	11th gen laptop chips and mini PCs

Stream counts come from other tests, and we link them instead of repeating them. Our N150 and N355 comparison quotes a median of four 4K HEVC streams to 1080p for the Alder Lake-N iGPU, or two with tone mapping. The transcoding GPU guide covers discrete cards and the stream test we use, and our mini PC picks for Jellyfin cover a ready-made box if you would rather not build one.

Which one fits your house? Match the engine to the clients you actually have, using these rules:

• N150: your own TVs and one or two phones
• A310: remote viewers who need AV1
• A310: a desktop with a free slot already
• Either: Ubuntu 26.04 or another recent kernel

Both chips need a recent kernel, and Ubuntu 26.04 already ships one that clears both floors. If you plan to stay on an older LTS release, check the kernel version before you buy the hardware, because an N150 on an old kernel shows no render node at all.

Step 2: Build the low-power N150 NAS box

Build A is a dedicated box: an 8-SATA mini-ITX board in a five-bay Jonsbo N2, one of the cases in our NAS case guide. We wanted the N355 for this build, but every 3.5-inch N355 board we found on Amazon US shipped in its N150 version. The N150 has the same media engine. ServeTheHome measured an N150 version of a small CWWK M.2 NAS at 10 to 11 W idle at the wall with one SSD, so expect this bigger board, its 10GbE port and two hard drives to idle higher.

Part	Price band	Pick
Board	about $270	8-SATA mini-ITX NAS board, Intel N150, 10GbE
Case	about $130	Jonsbo N2, five 3.5-inch bays
Power supply	about $100	SilverStone ST45SF V3 450 W SFX
Memory	about $255	Samsung 16 GB DDR5-4800 SO-DIMM
Boot NVMe	about $125	WD Blue SN5100 500 GB
Media drives	about $425 to $460 each	2x WD Red Plus 10 TB

That comes to roughly $880 before drives and about $1,730 to $1,800 with two 10 TB disks, depending on the drive price that day. Memory is the surprise line, because a single 16 GB DDR5 SO-DIMM now costs nearly as much as the board. The N150 runs one memory channel, so one stick is all it can use anyway.

Check two things before you order. The N2 takes one low-profile, single-slot card and an SFX supply up to 150 mm, so the two-slot ASRock A310 will not fit; only a single-slot card like the Sparkle A310 ECO would. The Jonsbo N3 takes eight drives and a two-slot card up to 250 mm, but check that your board has an x16 slot first, because the A310 needs one and the board listing only promises a PCIe Gen3 slot.

Step 3: Or add an Arc A310 to a desktop you own

Build B skips the dedicated board. An Arc A310 is bus powered, needs no extra cable, and adds AV1 encoding plus two media engines to any desktop with a free x16 slot. Intel lists it as PCIe 4.0 x8 in an x16 connector, so an older PCIe 3.0 board still works.

Slot width is where this build goes wrong. The ASRock low-profile A310 has a dual-fan cooler that takes two slot widths, and the Sparkle A310 ECO, the single-slot option, had no Amazon buy box when we checked. A reviewer of the Dell OptiPlex 3080 SFF notes its x16 slot sits next to the power supply, so a two-slot card does not fit that office PC. Many renewed small form factor PCs on Amazon share that layout, so measure the space beside the slot before you pair one with this card.

So which desktop works? Check these before you order the card:

• A free x16 slot, even if it runs at x8
• One empty slot width beside it
• A bracket that matches the case height
• Kernel 6.2 or newer
• ASPM enabled in the BIOS

A tower or mini-tower usually passes the slot checks. ASPM matters because the Jellyfin and Intel docs both say Arc cards need it to idle low, so look for it in the BIOS before you blame the card for a high idle draw. If your case takes full-height cards, the Sparkle Arc A380 ELF costs less, sells from Amazon directly, and adds 2 GB of memory.

Step 4: Size the drives and the NVMe

Media size depends on the source. Our 4K HDR10 test file ran at 59 Mbps, which works out to about 26.6 GB per hour of video. The disc specs set the ceilings, so you can plan capacity from them:

Source	Highest bitrate	Storage per hour at that rate
1080p Blu-ray	48 Mbps	about 21.6 GB
4K UHD Blu-ray, 66 or 100 GB disc	92 to 144 Mbps	about 41 to 65 GB
Our 4K HDR10 test file	59 Mbps	about 26.6 GB

At those rates a 10 TB drive holds roughly 100 to 200 two-hour films as 4K remuxes, and more as 1080p. Buy CMR drives only, because the Jellyfin hardware guide warns that SMR disks give a very poor experience for its own files. Our CMR and SMR guide lists which models are which.

We picked the WD Red Plus 10 TB because it was the only NAS drive in our search sold by Amazon itself. It is CMR, rated for up to eight bays, and idles at 4.6 to 6.1 W depending on the model number. Compare price per TB in our NAS hard drive guide before you buy several.

Put these on the NVMe, not on the hard drives, so that spinning disks only serve finished media files:

• The operating system
• The Jellyfin database and metadata
• The transcode cache

You will feel the difference most with the cache. The Jellyfin hardware guide suggests sizing it as your largest file times the number of concurrent streams, so a 60 GB remux played three ways needs 180 GB at worst.

Step 5: Install Jellyfin from the official repository

We installed on Ubuntu 26.04, which the Jellyfin repository builds for under the codename resolute. On Debian 13 the repository steps work with debian and trixie in the source file, but Step 6 differs, because Debian 13 has no intel-opencl-icd package. Start by creating the keyring folder and adding the repository signing key:

sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://repo.jellyfin.org/jellyfin_team.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/jellyfin.gpg

The Jellyfin docs write the source file with a heredoc, which breaks easily when you paste it from a web page. A single printf piped to tee produces the same file, and you can paste it as one line:

printf 'Types: deb\nURIs: https://repo.jellyfin.org/ubuntu\nSuites: resolute\nComponents: main\nArchitectures: amd64\nSigned-By: /etc/apt/keyrings/jellyfin.gpg\n' | sudo tee /etc/apt/sources.list.d/jellyfin.sources

The command echoes the file back, which is your check that every line landed. A missing Signed-By line is the usual reason apt later refuses the repository:

Types: deb
URIs: https://repo.jellyfin.org/ubuntu
Suites: resolute
Components: main
Architectures: amd64
Signed-By: /etc/apt/keyrings/jellyfin.gpg

The Jellyfin Intel guide says to remove the deprecated jellyfin metapackage if it breaks dependencies, while its install page still uses it. We checked what the metapackage pulls in on Ubuntu 26.04 first:

sudo apt-get update
apt-cache depends jellyfin

It already depends on the current FFmpeg build, so the metapackage is safe here and you do not need to install the FFmpeg package separately:

jellyfin
  Depends: jellyfin-server
  Depends: jellyfin-web
  Depends: jellyfin-ffmpeg8

Install it, then confirm the versions and that the server listens on port 8096. If the last command prints inactive, failed or activating instead of active, the service did not start, and journalctl -u jellyfin shows why:

sudo apt-get install -y jellyfin
dpkg-query -W jellyfin jellyfin-server jellyfin-web jellyfin-ffmpeg8
systemctl is-active jellyfin && sudo ss -tlnp | grep 8096

Our run reported these package versions, with the service up and listening:

jellyfin	12.2+ubu2604
jellyfin-ffmpeg8	8.1.3-1-resolute
jellyfin-server	12.2+ubu2604
jellyfin-web	12.2+ubu2604
active
LISTEN 0      512          0.0.0.0:8096      0.0.0.0:*    users:(("jellyfin",pid=6839,fd=264))

Jellyfin now answers on port 8096.

Step 6: Give Jellyfin the GPU and the OpenCL runtime

Jellyfin talks to the GPU through its render node, and it needs the OpenCL runtime for HDR tone mapping. If you run Jellyfin in a Proxmox container, pass the render node in first. Get the render group ID from inside the container with getent group render, then set the device on the host and reboot the container:

pct set 251 --dev0 /dev/dri/renderD128,gid=991,mode=0660
pct reboot 251

Device passthrough with dev0 needs Proxmox VE 8.2 or newer. A container also runs on the host kernel, not on Ubuntu, so the host must clear the kernel floor: the default 6.8 kernel on Proxmox VE 8 is too old for an N150 and sits in a range with known i915 bugs on Arc A cards, so use the opt-in 6.14 kernel or Proxmox VE 9 for either build. On bare metal, skip straight to checking that the render node exists:

ls -l /dev/dri

You should see a renderD128 device owned by the render group. On a box with an iGPU and an A310 together, the A310 usually shows up as renderD129, so use that node everywhere this guide says renderD128:

total 0
crw-rw---- 1 root render 226, 128 Oct 21 22:26 renderD128

Many guides tell you to add the jellyfin user to the render group by hand. On Ubuntu 26.04 the install script inside the package already does it whenever that group exists, and id confirms it:

id jellyfin

The 991(render) entry is the one that matters. If yours is missing, add the user with sudo usermod -aG render jellyfin and restart the service:

uid=103(jellyfin) gid=107(jellyfin) groups=107(jellyfin),44(video),991(render)

jellyfin-ffmpeg ships its own Intel media driver but not the OpenCL runtime, so install that from Ubuntu. Check the version first, because Jellyfin asks for 23.xx or newer on N-series chips:

apt policy intel-opencl-icd intel-media-va-driver-non-free 2>/dev/null | grep -E '^[a-z]|Candidate'
sudo apt-get install -y intel-opencl-icd

The policy output shows the candidate versions Ubuntu will install:

intel-opencl-icd:
  Candidate: 26.05.37020.3-1
intel-media-va-driver-non-free:
  Candidate: 26.1.2+ds1-1

A310 owners need one extra check, and we did not run this path in the lab. The Jellyfin known issues page says compute runtime versions from 25.18.33578.6 onward are broken on Arc A cards, and the Ubuntu 26.04 package falls in that range. If tone mapping fails on an A310, install 25.13.33276.16 from Intel’s compute-runtime releases on GitHub, or run the official Jellyfin Docker image instead. Debian 13 users need the same GitHub packages, since Debian ships none.

The install also pulled in a second package, intel-opencl-icd-legacy, and registered two OpenCL drivers. To see which one actually drives the GPU, ask OpenCL as the jellyfin user:

sudo apt install -y clinfo
sudo -u jellyfin clinfo -l

Only one platform answered for the Iris Xe. clinfo without -l reports a driver version that matches the main package rather than the legacy one, and the N150 and N355 iGPUs belong to the same Gen12 family:

Platform #0: Intel(R) OpenCL Graphics
 `-- Device #0: Intel(R) Iris(R) Xe Graphics

Last, list the media profiles with the vainfo that Jellyfin ships, so you test the same driver the server will use:

sudo /usr/lib/jellyfin-ffmpeg/vainfo --display drm --device /dev/dri/renderD128 2>&1 | grep -E 'Driver version|VAProfileHEVCMain10|VAProfileAV1|VAProfileH264High'

Look for EncSliceLP on HEVC Main10 and H.264, which are the low-power encoders Jellyfin will use. The AV1 line shows only VLD, which means this chip decodes AV1 but cannot encode it:

vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 26.3.5 (1b5e662)
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointFEI
      VAProfileH264High               :	VAEntrypointEncSliceLP
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileHEVCMain10             :	VAEntrypointEncSlice
      VAProfileHEVCMain10             :	VAEntrypointEncSliceLP
      VAProfileAV1Profile0            :	VAEntrypointVLD

An A310 adds an AV1 encode line to that list. If an entry you expect is missing, check the kernel version before anything else, because an old kernel exposes the GPU without its media features.

Step 7: Run the setup wizard and add the library

Open http://10.0.1.50:8096 in a browser, replacing the address with the one your server got. The wizard asks for a language, then the admin account. Use a real password, because this account controls every setting on the server:

On the library page, add one library per content type. We pointed a Movies library at /srv/media/movies, which sat on the NVMe in our lab and would sit on the hard drives in a real build:

Finish the remaining wizard pages with their defaults. Leave remote access on only if you will put the server behind a reverse proxy, since Jellyfin says it is not designed to face the internet directly.

Step 8: Turn on Intel Quicksync (QSV) in the dashboard

Hardware acceleration is off after install. Open Dashboard, then Playback, then Transcoding, and set these in order:

1. Hardware acceleration: Intel Quicksync (QSV)
2. QSV Device: /dev/dri/renderD128
3. Decoding: H264, HEVC, MPEG2, VC1, VP8, VP9, AV1
4. 10-bit decoding: HEVC 10bit and VP9 10bit
5. Encoders: both Intel Low-Power boxes
6. Tone mapping: Enable Tone mapping

Tick AV1 decoding only if the chip has it. Every chip in this guide decodes AV1, but older Quick Sync generations do not:

Further down, turn on both low-power encoders and the OpenCL tone mapping. We left VPP tone mapping off, because our transcoding guide measured the OpenCL path slightly faster on the same Iris Xe:

Leave HEVC and AV1 encoding off unless your clients play them, because Jellyfin then picks those formats for any client that claims support. Save at the bottom of the page, and accept the warning about hardware acceleration that pops up after you save.

Step 9: Prove it with one real transcode

Play the hardest file you own from a client that cannot play it directly. We played our 4K HEVC HDR10 test file in Chrome, which has no HEVC support, and opened the info button on the session in the dashboard:

That session kept the 4K resolution and encoded H.264 at 62 Mbps, because the browser asked for full quality. It ran at 77 fps, about 1.25 times real time for a 60 fps file. Most phones on mobile data ask for 1080p or lower, so we requested an 8 Mbps 1080p stream next.

Each transcode writes its own log file, named with the date and the item ID, and the last frame line holds the average speed for the whole run. The log folder is readable only by root, so list the newest logs with sudo:

sudo ls -t /var/log/jellyfin/ | head -3

The newest FFmpeg.Transcode file is the session you just played. Pass its name to grep in place of the file name below, which is the one from our 1080p run:

sudo grep -ao 'frame=.*speed=[ 0-9.]*x' /var/log/jellyfin/FFmpeg.Transcode-2026-10-21_22-57-59_dc80ba7f9805c3f4f5ad72ca730da10b_177c38a3.log | tail -1

The 1080p log confirmed the full hardware path: VA-API decode, scale_vaapi, tonemap_opencl and the h264_qsv encoder. Its final line:

frame= 1797 fps=195 q=24.0 Lsize=N/A time=00:00:28.70 bitrate=N/A speed=3.12x

A real-time 60 fps stream needs about a third of the 195 fps this one transcode reached flat out. That is a single-stream number from an Iris Xe, so treat it as proof that the setup works, not as a stream count for an N150 or an A310. If you want a real stream count for your own box, run several transcodes at once with the harness from our transcoding GPU guide, and stop adding streams once the frame rate falls under the source rate. Our ffmpeg encode timings on a 4 vCPU box show what software transcoding costs before you add hardware acceleration.

Fix the errors from the first transcode

These came up while we built the lab, or are the ones the Jellyfin docs warn about for these chips. Each heading is the message you will see, followed by what fixed it for us.

unsupported Ubuntu version ‘26.04’ when creating a container

Our Proxmox host refused the Ubuntu 26.04 template with this message:

unable to create CT 251 - unsupported Ubuntu version '26.04'

The cause is an out-of-date pve-container package, not Proxmox VE 8 itself. The pve-container changelog added Ubuntu 26.04 in version 5.3.3, and our host was still on 5.3.0. Update the host with apt update and apt full-upgrade, confirm with pveversion -v | grep pve-container, and create the container normally.

We worked around it with --ostype unmanaged instead, which skips the network setup that Proxmox normally does, so the container came up with no address. A systemd-networkd file for eth0 with DHCP=yes fixed that, but updating the host is the cleaner fix and keeps Proxmox managing the network.

The transcode stays at 4K and the bitrate is huge

A browser that asks for full quality gets a 4K H.264 stream at close to the source bitrate, as our first session did. That is correct behaviour, not a failed tone map. Set the quality in the client to 1080p or lower to test the path most remote viewers will use.

Failed to get number of OpenCL platforms: -1001

This means the OpenCL runtime is missing, so tone mapping fails while plain transcodes still work. Install intel-opencl-icd as in Step 6, then confirm with clinfo -l as the jellyfin user. The Jellyfin Intel acceleration page also lists a known runtime regression on Arc A cards, so check its known issues if an A310 fails here.