Tvheadend

I use my NAS mounted over NFS4 for my recordings and timeshift buffers. I should note, though, that it is mounted NFS4, which is TCP and not UDP like previous versions of NFS. For raw speed, UDP will give you better performance. However, I was previously using a share from the NAS mounted via CIFS, so even NFS over TCP is an improvement.

It depends on what you will record (SD, HD ie 2-10+ Mbps streams) and more so on how many simultaneous recordings/playbacks you foresee occurring. Also factor in if you are using a SAT>IP unit, the stream will go from the SAT>IP server -> Tvheadend -> NAS resulting in double network usage for each stream. Same goes for playback: NAS -> Tvheadend -> client.

I record some content to an NFS mount on an old Linux PC and never had any problems, although I doubt I ever went over 25Mbps in total recordings/playbacks at the same time.

As far as TCP vs UDP, I recently had to switch one NFS server from UDP to TCP because I enabled jumbo frames on my network, but my satellite stb does not support jumbo frames and thus could not use UDP. (For TCP it negotiates the correct frame size and works fine.) Anyway, concerned about loss of performance, I did some speed tests between the server and another linux box and found the difference between TCP and UDP to be trivial for NFSV3 and NFSV4 TCP marginally faster than NFSV3 UDP. I found more differences in adjusting rsize, wsize and of course enabling jumbo frames.

Great thanks. The NAS has two network connections with LAG enabled so it can distribute access over multiple connections to multiple machines, so recording from the Sat>IP stream and then feeding others shouldn't be an issue. The vSAN cluster has quad NICs per machine, so each VM has LAG enabled networks at the vsphere level and running a fake 10G connection via the vmware specific VMNET3 NIC.

Chris Beasley wrote:

Great thanks. The NAS has two network connections with LAG enabled so it can distribute access over multiple connections to multiple machines, so recording from the Sat>IP stream and then feeding others shouldn't be an issue. The vSAN cluster has quad NICs per machine, so each VM has LAG enabled networks at the vsphere level and running a fake 10G connection via the vmware specific VMNET3 NIC.

Seems like you have a good grasp on what your network can handle, so you can do the math and decide if the amount of streams it can handle will be enough.

Another option might be to run Tvheadend directly on the NAS...

Yeah I had considered running it on the NAS, I can use a docker image and give it direct access to the drives which will not be an issue with data transfer, and with the 2 NICs in LAG, that will allow concurrent access to TVH.. I did try the image but I had some trouble with it working as the memory usage of the docker image never increased too far... I haven't tried an SPK yet but I might do that...

Or you could be adventurous and try to build it yourself. I do not have the hardware and so have not personally done it, but I have seen some people have posted instructions how.

Another issue you may have with running Tvheadend on your NAS is with transcoding (if it is something you will use.)

building myself I've always found to be awkward, I'm not a native Linux user.. I know enough to break the system, but not deal with some of the other issues that may arise as a result!

I got the docker image working last night, runs fine, minimal memory usage but I still can't get my other machine with the tuner cards working as a Sat>IP server... will play some more. In reality, my NAS is not actually a physical NAS, more a virtualised Synology DSM install using Xpenology running on a vSphere 6.5 cluster with 8/16 core Xeon CPUs per host and 128GB total Ram. I don't intend to transcode as my devices are powerful enough to decode H.264/5 natively. I'll probably still run a virtualised on vpshere directly TVH server, but playing with the docker for fun!