Tvheadend

USB drive will not have enough I/O and bandwidth speed.
Some NAS solution will be better,

Thanks saen,

How could I test the I/O in the USB disk?

Kind regards.

https://www.thomas-krenn.com/en/wiki/Linux_I/O_Performance_Tests_using_dd
in multiple terminals

Thanks saen!

I just try it:

# dd if=/dev/zero of=/mnt/USB/testfile bs=256M count=1 oflag=direct
1+0 records in
1+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 12.3071 s, 21.8 MB/s

# dd if=/dev/zero of=/mnt/USB/testfile bs=512 count=1000 oflag=direct
dd: error writing '/mnt/USB/testfile': Invalid argument
1+0 records in
0+0 records out
0 bytes copied, 0.0206575 s, 0.0 kB/s

The first one give me 21.8 MB/s and the second one fail.

Is this enough for 3-4 simultaneous HD streams?

Kind regards.

Be sure what is Bitrate of programs!
Because HD channels use 6~20 Mbps
if this is for recording OK, but timeshift write and read simultaneously
best solution for timeshift is RAM storage or good RAID
(SSD drive finish his live for less then year, sometime faster 2-5 months)

WD PiDrive

21MB/s = 168 Mb/s so the I/O speed of the disk is good enough for quite a few streams. (Important to remember 1MB/s=8Mb/s (B = Byte, b = bit)

Average bit rate of UK DVB-T2 streams are around 4-5Mbs (i.e. 0.5MB/s, with peaks at 17Mbs, or just under 2MB/s). Looking at diigtalbitrate http://www.digitalbitrate.com/dtv.php?liste=1&live=69&lang=fr&mux=10847 the DSat figures seem about the same.

HOWEVER - all the USB tuners and the hard drive (and Ethernet connection if used) will be sharing a single USB 2.0 bus (that's a fundamental hardware limitation on all Pis) - so you need to be aware of that.

Personally for a single or dual tuner DVB-T/T2 set-up the Pi is fine in my experience. However for a larger set-up I'd go for an x86 solution. (I have 9 tuners sitting on a Chromebox with a USB3.0 hard drive so I can watch and record channels on all or every UK mux)

1 megabyte = 8 megabits
however I/O speed reduce performance when multiple streams r/w used
That's why server disk have 64Mb+ cache

Repeat upper test with /dev/random if cpu survive

make test and measure time

dd if=/dev/random of=/mnt/USB/testfile1 bs=2048M count=1 oflag=direct
dd if=/dev/random of=/mnt/USB/testfile2 bs=2048M count=1 oflag=dsync

dd if=/dev/random of=/mnt/USB/testfile3 bs=2048M count=1 oflag=direct && dd if=/dev/random of=/mnt/USB/testfile4 bs=2048M count=1 oflag=dsync && dd if=/dev/random of=/mnt/USB/testfile5 bs=2048M count=1 oflag=direct && dd if=/dev/random of=/mnt/USB/testfile6 bs=2048M count=1 oflag=dsync

dd if=/mnt/USB/testfile1 of=/dev/null bs=2048M count=1 oflag=direct

If your HD streams are maximum of 20Mbps and you have four recordings then you will be reading 4*20 from the tuner (=80Mbps) and writing the same to either disk or Ethernet (Pi shares Ethernet processing with USB bandwidth). So that makes a total of 160Mbps. If you're playing back two streams too then that's reading 2*20Mbps from disk and writing 2*20Mbps to the network. So that's a further 80Mbps.

So the total you have is:
USB2: 480Mbps
Recording: 160Mbps
Playback: 80Mbps

So total USB bandwidth would be 160+80=240Mbps of the 480Mbps (excluding overheads of the protocol of say 10%l).

I'd say it could probably handle it (since we're measuring peaks rather than average bitrates), but you might get "bus resets" where something times out and then reconnects. Remember also that data isn't written direct to the disk, but is cached by the kernel and only written periodically, say every 30 seconds and this has an impact on your peaks.

I'm surprised your USB disk is so slow but that is probably a limitation in the Pi. I'd expect twice that speed.

For filesystems, I've used most of them over the years. There's practically no difference for a home user since the throughput of broadcast data is so low.

Assuming you are sticking with Linux, nowadays I'd recommend "btrfs" since it allows you to easily replace one disk with a larger disk in the future with one command, whereas most other filesystems need you to do relatively tedious sync of data and editing of config files and shutdowns. I don't know how well it performs on the Pi. Otherwise, ntfs-3g would allow you to take the drive and plug it in to your Windows box if that's something you might need to do.

USB have lot of limitations
IRQ limiter №1
480Mbps on paper
USB to Sata controller also reduce speed (guess why more "good" brands have external power supply
each next write stream add lag to speed, fill disk cache and reduce speed + Fragmentation etc.

Whatever you calculate reduce it with at less 20%

In case people find this via a search engine, I'll remove my recommendation for btrfs for recordings, at least on a 4.1x kernel.

I use a separate internal disk for recordings and I've had far too many problems now the dedicated disk had become near full (~40GB spare) with it frequently taking the volume read-only (and needing a reboot to make it r/w since it refuses umount or remount). I've also had to start defragmenting recordings to avoid occasional really poor read performance that I've never had on other CoW filesystems that were similarly full with many more rewrites.

Of course one could argue that you shouldn't let your disk get full or perhaps I've been unlucky with my kernel versions; but system basics like disk writes should not need reboots.