Building a small home theatre PC for live TV
The CPU matters less than you think and the RAM matters more. We have the measurements to say why.
A small PC under the television is the most capable version of this app, because the desktop head gets everything first: catch-up, recording, multiview, picture-in-picture, HDR output and audio passthrough. The question is what to buy, and the usual advice gets the priorities backwards.
Memory first, and here is why
We profiled a Release build over a fixed route through the pages people live in, three times through, on a machine with far more headroom than any box under a television. The result is worth being straight about.
A 12 minute browse session ended at 918 MB of working set and peaked at 1,080 MB, against an internal budget of 400 MB. Across the three identical cycles the working set went 827, then 895, then 918 MB, measured after forced collections each time.
The managed heap was flat over exactly the same cycles: 61.1, then 62.6, then 62.5 MB. So the growth is not garbage waiting to be collected and it is not cache policy. It is native memory. It does not come back within a session.
That is a live issue rather than a design, and it has a direct purchasing consequence: do not build this machine with 4 GB. 8 GB is the floor and 16 GB is the comfortable answer, because Windows plus a browser plus a player that can reach 1 GB on its own does not fit in 4.
The good news from the same run: responsiveness held. The UI thread never blocked for more than 392 milliseconds across the whole route and never stopped pumping messages. Memory needs the headroom, not the CPU.
Which decoding matters
Hardware decode is a setting with 3 states, Auto, On and Off, and Auto is correct for almost everyone. What it selects is a GPU decoder, and any integrated graphics from the last several years handles H.264 and HEVC without the CPU noticing.
We got this wrong ourselves for a while, and it makes a useful warning. Until 2026-08-23 the on-demand path hard-coded hardware acceleration off, so every film was software decoded no matter what the setting said, while live TV honoured it correctly. After the fix, a 4K HEVC Main10 title ran with the GPU decode engines at about 11 percent. Same file, same machine, same setting.
The lesson for a build: check that hardware decode is engaging rather than assuming it from the setting. The stream information panel will tell you. Hardware versus software decoding covers how to read it, and H.264, HEVC and AV1 covers which codecs your chosen chip will and will not accelerate. AV1 is the one to check on a budget part.
A build that works
CPU any modern integrated-graphics part with HEVC decode
RAM 16 GB, 8 GB floor, not 4
Storage NVMe. Recordings are local files and they are large
Network wired if the wall socket is anywhere near
Case fanless if you can, this box sits next to your ears
The wired network line is the one people skip and then spend a weekend on. A live stream is a continuous read that has to keep up in real time, and marginal wireless is the single most common cause of stuttering that looks like a player problem. Fixing buffering and stuttering starts there for a reason.
Storage deserves one more line. A recording is a remux, not a re-encode, so the file is exactly as large as the broadcast, and it lives on the machine that made it. If the internal drive is small, recordings can go to a network share instead, with a connection test before you commit to it.
Settings to change once it is built
Turn on HDR output if the television is HDR. Auto is the safe default: it asks for a 10-bit surface only when the display it is on reports an HDR colour space, and any probe failure answers SDR. On a dedicated HTPC where the display never changes, Always is defensible.
Turn on audio passthrough if there is a receiver in the chain. One caveat first: passthrough opens the audio endpoint in exclusive mode. That is why it is restricted to the primary player, and it means other applications lose that output device while it is active. On a dedicated box that is exactly what you want. On a machine you also use for anything else, it is a surprise.
Leave hardware acceleration on Auto unless you are debugging.
What an HTPC gets that a console does not
Everything, roughly. Catch-up, recording, multiview from 2 to 9 tiles, picture-in-picture, HDR, passthrough and the full keyboard map. The console head links a different native player library and is behind on several of those: 4K and HDR on Xbox is the specific list.
If you do not want to build anything, connecting a laptop to the television over HDMI gets you most of the same result for an evening's effort, and starting the app with Windows makes either one feel like an appliance.
What this article measured21 claims, each with the evidence behind it
| Claim | Evidence | Counted |
|---|---|---|
| A 12 minute browse session on the desktop head ended at 918 MB working set and peaked at 1,080 MB, against a documented internal budget of 400 MB. | n = 3 | Aug 30, 2026 |
| The growth is native rather than managed. Across the same three cycles the retained managed heap was flat at 61.1, 62.6 and 62.5 MB while the working set climbed by about 91 MB. | n = 3 | Aug 30, 2026 |
| Responsiveness held up over the same route: the UI thread never blocked for more than 392 milliseconds and never stopped pumping messages. | n = 1 | Aug 30, 2026 |
| Hardware acceleration is a user setting with three states, Auto, On and Off, applied as an avcodec hardware switch to live TV, multiview and on-demand alike. | n = 1 | Aug 20, 2026 |
| Until 2026-08-23 every film and episode was software decoded, because the on-demand path hard-coded hardware acceleration off. After the fix a 4K HEVC Main10 title ran with the GPU decode engines at around 11 percent. | n = 1 | Aug 23, 2026 |
| The memory profile is not a single counter: four independent sources were joined on one clock so a spike could be attributed to the page that caused it rather than to the run as a whole. | n = 4 | Aug 30, 2026 |
| Heap snapshots force a full blocking generation-two collection before walking the heap, which is what makes the reported figures retained memory rather than garbage that had not been collected yet. | n = 1 | Aug 30, 2026 |
| Private bytes told the same story as the working set across the three cycles, 719 then 792 then 835 MB, so the growth is not an artefact of one counter. | n = 3 | Aug 30, 2026 |
| The profile drove the pages people actually use, Home, Live TV, Movies, Shows, Catch-up and the guide, as a fixed route of named phases repeated three times, rather than a synthetic loop. | n = 3 | Aug 30, 2026 |
| The measurement machine had far more headroom than a small home theatre PC would: 32 logical cores and 125.6 GB of memory, so the figures are not a constrained-hardware artefact. | n = 1 | Aug 30, 2026 |
| The acceleration setting maps to three decoder selections rather than a boolean: a Direct3D 11 decoder, any available decoder, or none. | n = 3 | Aug 20, 2026 |
| Decoder frame threads cost GPU-visible memory rather than only CPU time: six threads produced a 40-surface output pool at 4K, roughly 500 MB. | n = 1 | Sep 1, 2026 |
| HDR Auto reads the colour space of the display the window is actually on, so a dedicated box whose display never changes behaves deterministically. | n = 1 | Aug 23, 2026 |
| Forcing HDR on a display that is genuinely SDR makes the player output PQ, which looks washed out, so the escape hatch is for panels that under-report rather than a quality setting. | n = 1 | Aug 23, 2026 |
| Recording is a remux rather than a re-encode, so the file is exactly as large as the broadcast, and it lives on the machine that made it: the server holds no recording data at all. | n = 1 | Sep 1, 2026 |
| Recordings can be written to an SMB network share as well as local disk, with a connection test, which matters on a small machine whose internal storage fills quickly. | n = 2 | Sep 1, 2026 |
| The desktop package is self-contained by default, so a freshly built machine needs no runtime installed first, while the application framework ships alongside it. | n = 1 | Sep 1, 2026 |
| Multiview runs from 2 to 9 tiles, each its own player instance, which is the single heaviest thing a small machine will be asked to do. | n = 6 | Sep 1, 2026 |
| Tiles are capped at 640 by 360 muted and 1280 by 720 with audio, which is what makes a nine-tile grid feasible on ordinary hardware. | n = 1 | Aug 23, 2026 |
| Warm launch to Home came down from 11.6 seconds to about 4.6, and picking a profile to reaching Home was roughly halved to about 1.2 seconds. | n = 1 | Sep 1, 2026 |
| Bitstream audio passthrough opens the audio endpoint in exclusive mode, which is why it is restricted to the primary player and why other apps lose that device while it is active. | n = 1 | Aug 23, 2026 |