Personal Video Recorder

The Requirement

TiVo revolutionised video-recording. The video-tapes & the error-prone spinning video-head were replaced by a hard-disk, & the increasingly wide TV-schedule was available as dial-up service; they had invented the PVR. Regrettably, TiVo's UK-debut in 2000 with the Thomson PVR10UK, failed after an advertising campaign which focussed solely on the ability to pause live TV, & the ≈2007 migration from terrestrial analogue broadcasting to DVB was the final nail in the coffin. Though over a decade has passed since TiVo's fall (except as offered by Virgin Media), other PVRs haven't reproduced the user-experience. In my experience, they're typically:

The Solution


There are a variety of open-source s/w-projects based on GNU/Linux & kodi (formerly XBMC), which provide not only PVR-functionality but can double as a media-player:

Raspberry Pi model 3B


In 2012 the Raspberry Pi became available. The model 3B provides:

  • a 4-core processor,
  • Ethernet & WiFi,
  • hardware-accelerated h.264-decoding.

This is sufficiently powerful to run kodi, & is quite inexpensive. Many people have pioneered such solutions, but I've detailed my specific solution & conclusions.

Component Type # Size
Acrylic sheet Clear 1 A3 × 3 mm
Tube Aluminium 4 (72 × 12 × 1) mm
Foot Rubber 15 mm
Threaded rod Stainless steel 10 cm × M3
Nut 8 M3
Washer Penny 12 1 cm
Raspberry Pi Model 3B 1
Power-supply µB USB output-plug 5 V DC × 2.5 A
µSD-card Class-10 8 GB
Real-time Clock DS3231
Standoff Male-female 6 M2.5
Cable HDMI 1 Standard
Acrylic bar Square-section 1 4 cm × 5 mm2
Solvent Tensol 12
Cable-tie Black 20 cm × 2.5 mm
Tuner USB 2.0 DVB-T2 2
RF-adapter Male-male
Cable Male-female USB Type-A, 25 cm
RF-splitter 2-way inductive 1
Bolt Hex socket 2 8 mm × M3
Nut M3
RF-adapter Female-female 1
Hard-disk drive SATA 2 2.5", 500 GB
Adapter SATA 3 to USB 3.0 Standard, Type-A
Bolt Hex socket 8 8 mm × M3
Grommet Rubber 10 mm × 3 mm
Flash-drive USB 1 Standard, Type-A
USB-hub USB 3.0 1 4-port, 15 W
Cable-tie Black 2 20 cm × 2.5 mm
Strip-board 1 64 mm × 25 mm
Operational amplifier LM324 Quad
LED Red 4 5 mm
Potentiometer Multiturn 100 kΩ
Resistor 0.25 W 47 Ω
Jump-wire 6 10 cm

From a glance at the list of parts, this is likely to be more expensive than the average commercial PVR, but then, they're not exactly the same product. Whereas a commercial PVR will probably give you a nose-bleed when you discover that it promised long & delivering short, this solution is:

  • networked; one can connect over ssh, or HTTP.
  • flexible; there are many s/w add-ons to enhance functionality.
  • open-source; so you can in principle, inspect the code to see how your data is being used.
  • supported; the update-frequency depends on the selected distribution.
  • repairable.
  • many of the parts are re-usable in other projects, or may previously have been purchased for abandoned projects.
  • it looks better; OK, that's subjective, but it reminds me of Orac.

If your unconvinced by these merits, you could reduce the cost:

  • by downgrading to merely one tuner (& also potentially remove the RF splitter & three gender-changers), preventing simultaneous recording.
  • by downgrading from DVB-T2 to the older DVB-T standard, limiting you to standard-definition broadcasts.
  • by downgrading to just one HDD / SATA-USB adapter, increasing the chance that video-files will be lost on failure.
  • by downgrading to a Raspberry Pi Zero W, which with a single CPU, is slow but adequate. You'll also have to cope with a mini HDMI port & a single µUSB data-port.
  • the status-LEDs can be omitted, if one is prepared to manually confirm that the HDDs & DVB-tuners are available after booting.
  • the battery-backed real-time clock can be omitted provided that the network is available when booting, to permit synchronisation with an NTP-server.
PVR (plan) PVR (end elevation) PVR (side elevation)


The case is built from acrylic.

  • This typically comes covered by protective plastic, which shouldn't be removed until completion.
  • The A3 sheet is scored & snapped over a straight edge (which takes considerable force), into two A4 halves; one could merely buy A4 sheets, but that's slightly more expensive. The sheets can then be clamped together to reduce the effort of subsequent processing & to force alignment of those holes they share.
  • The corners are ground to a radius of ≈1 cm; a coin can be clamped to form a guide for the file. This is largely aesthetic, though my sheet of acrylic arrived by post, with one corner pre-mashed.
  • Various holes were drilled using HSS twist-drill bits.
    • For accuracy a drill-stand was used, after piloting each hole by hand using a pin-vice & a 1 mm drill-bit (which easily bites into the relatively soft protective plastic).
    • Acrylic has a tendency to ride up the thread of the drill-bit, & since it's brittle, the consequences are typically catastrophic, so each hole was progressively enlarged 1 mm at a time; for holes ≳7 mm diameter, a step drill-bit or hole-saw is probably required.
    • The sharp 90° corner of larger holes can be rounded using a countersink.
    • Excess heat can melt & discolour the acrylic, so a low drill speed was used.
    • Wood was placed beneath the acrylic to prevent chipping round the exit-hole when the drill-bit emerges from the far side.
  • A square-section acrylic bar is bonded to the lower face of the upper plate, between 2 holes from which both DVB-tuners are suspended using a cable-tie.

The two horizontal sheets are connected by vertical aluminium tubes, one at each corner, through each of which a threaded rod is inserted. Penny-washers are used to spread the load from the tightened threaded rods, to avoid cracking the acrylic. The length of these tubes plus twice the thickness of a penny-washer, should equal the 70 mm width of the HDD plus the thickness of the grommets.

Rubber feet must be threaded onto the lower end of the threaded rods, since otherwise various protruding bolt-heads & cable-ties would prevent the case from sitting horizontally.


The Raspberry Pi is attached to the acrylic base-plate using 12 mm long standoffs to enable subsequent removable of the µSD-card using one's fingers rather than tweezers. The upper end of the standoff must be female since there's insufficient space to tighten a nut; the lower end can be either gender.

There was apparently no need to attach a heat-sink to the Broadcom BCM2837 SoC. While recording two high-definition channels & watching a standard-definition recording, the temperature rose from a quiescent 39 C, to 48 C; well below the 80 C at which throttling occurs.

Though the Raspberry Pi has 4 USB-2.0 ports, it only has a single bus, limiting the data-rate to a theoretical 480 Mb/s. In the UK, each DVB-t2 tuner requires about 40 Mb/s. Though each HDD has a SATA 6 Gb/s interface, it won't be required to write any faster than both DVB-t2 tuners can receive. So if recording two HD channels while watching a third, the total requirement (200 Mb/s) is still within what might be expected from the USB-2.0 specification, provided that the Ethernet (implemented on USB) isn't being hammered for any unrelated reason.

The battery-backed real-time clock is connected to the GPIO-pins, but LibreELEC must be modified so that the kernel recognises it:

mount -o 'remount,rw' /flash;	# This file-system is normally mounted read-only.
echo 'dtoverlay=i2c-rtc,ds3231' >>/flash/config.txt;	# Append a line to the config-file.
hwclock -r	# Confirm the time.


The selected distribution is read from a µSD-card. Either a Sandisk Extreme Plus or Samsung Pro is compatible with the Raspberry Pi, & their high speed reduces the boot-time. Though 8 GB is sufficient for the smaller distributions, greater capacity costs little more. For installation, either follow "these instructions", or install NOOBS & select the required distribution.

Video files are recorded onto a level-1 RAID built from a pair of HDDs formatted with BTRFS. These were connected to the USB-hub via SATA-USB adapters, & to the case by rubber grommets to reduce transmission of vibrations.

Since kodi is not just a PVR, but a media-player, any audio files can be read from a USB flash drive. To avoid corruption of the file-system on power-loss:

echo "mount -o 'remount,ro' device" >>/storage/.config/


Two DVB-tuners were used, to permit simultaneous recording. I used a Geniatech MyGica T230 & a PCTV Systems tripleStick 292e, both of which worked seamlessly. DVB-T (Freeview in the UK) was piped to them via an RF-splitter. Initially I used a cheap 4-way splitter, which at best quarters the signal-power available to each output, resulting in a signal that was unacceptably weak, so I replaced it with a higher quality 2-way inductive splitter.

The assembly of RF-components was hung from the top plate of the case, taking care to distance them from the GPIO-pins rising from the Raspberry Pi.


The 7200 RPM Hitachi Z7K500s selected for storage of video files, require only ≈2 W each, but can draw a rather high 5.5 W on start-up (the 5400 RPM version is little better).

The power-requirements of both the HDDs & two 0.5 A DVB-tuners, exceed that which can be delivered from the USB-ports of the Raspberry Pi, so they're connected to a powered USB-hub; I used a 15 W Atolla 204u3. I selected a hub which conforms to USB 3.0, not because of its speed (since the Raspberry Pi to which it is connected only supports USB 2.0), but because it makes 0.9 A available to each device, which is necessary for the HDDs. The various USB-cables can be merely USB 2.0, though one might want to confirm that the power-wire is of an adequate AWG; I just used USB 3.0 ones.

Being low power (0.2 A), the USB flash-drive containing the audio files is connected directly to the Raspberry Pi, liberating all the ports of the USB-hub for higher power devices.

Back-powering the Raspberry Pi from the USB-hub also, bypasses protection & is generally deprecated, so it retains its own independent power-supply.


The Raspberry Pi is connected to a TV using HDMI. The primary input-device is the TV's remote-control via HDMI-CEC, so no separate infra-red receiver is required. CAVEAT: the HDMI-support on older TVs may not include CEC, or may need it to be enabled, & the manufacturer may refer to it using some fatuous brand-name (typically called "something-(link|sync)").

One can also connect over Ethernet, to:

Port Name Service
8080 Chorus kodi's web-UI
9981 Tvheadend kodi's backend for managing TV


Perhaps just when playing music, or also when watching a film, the output from the TV's internal speakers doesn't quite cut it. Your new TV may have a greater pixel-density than your eye can resolve, but the sound is probably no better than an old cathode-ray model; it's probably worse since the speakers typically face either backwards or downwards, to permit a stylish narrow front bezel.

One can connect an audio amplifier (& Hi-Fi speakers) to the TV's audio output (typically RCA sockets) rather than directly to the Raspberry Pi. The TV will probably have an item buried in its menu to redirect the audio signal. One could alternatively take the audio signal from the headphone jack on the Raspberry Pi.



The depicted circuit is powered from the Raspberry Pi's 5 V GPIO-pin, & can supply a constant current (irrespective of the LED's colour) to any of four LEDs, each according to the state of a dedicated GPIO-pin. Individual trimmer-potentiometers are available to fine-tune the brightness.

A daemon "", governs the state of the connected GPIO-pins, which can be started at boot-time using:

echo 'nohup /storage/.config/ --poll --period=15 &' >>/storage/.config/

This daemon could be used to continuously indicate arbitrary attributes of the PVR, but has been used to monitor the availability of the required h/w. CAVEAT: the script must be tailored because of hard-coded references to the attributes of specific h/w.

Both HDDs
References the file-system label.
USB flash-drive
References the file-system label.
PCTV Systems tripleStick 292e DVB-tuner
References the vendor & product.
Geniatech MyGica T230 DVB-tuner
References the vendor & product.

Failure to find some of this h/w might result from booting the whole system simultaneously. A more reliable procedure is to boot the USB-hub first (from which the above h/w is powered), & then the Raspberry Pi.


My impression is largely positive, but there are a few issues: