Is OMV going to work for me?

not sure what conflicting information you get bu here is my POV.

EXT4 is a reliable and tried FS. it is currently one of the most used across Linux distros except for XFS.
but it has some shortcomings that FS like ZFS and BTRFS are trying to eliminate.
i.e. EXT4 and a like, do not have self healing capabilities and no protection against data bitrot.
this FS need additional tools and modules for that and other capabilities.

FSs like ZFS and BTRFS fix that and add a built-in raid capability , built-in drive pooling and more.
I personally prefer BTRFS for my FS if I can use it.
there are planty of comparison on the net between BTRFS and ZFS so I am not going to go into this here, but will just do a very quick feature list for you to think off.

Both ZFS and BTRFS are CoW FS and both feature raid and drive pooling options.
however where BTRFS will happily let you mix drive sizes in the raid/pool setup
ZFS is more strict and more demanding. with BTRFS it is easy to switch between raid configs on the fly and expand or contract raid pool on a running system with only a mild slowdown, ZFS does not offer the same level of options as far as I can tell. you can do it , but it does require a more fiddling and CLI interaction with the system. hence why I favor BTRFS.
BUT
at the very moment BTRFS only offer Raid-0, 1 and 10 as stable code.
there is raid- 5 and 6 but it is still in unstable state and not recommended.
judging by my past experience I would not recommend using BTRFS on raw devices for raid and drive pooling , as I have lost data with that setup I only use BTRFS on partitioned drives.

RAW device is when you use the disk as is. no partition table and no partitions at all.
you can do this with LVM and mdadm, as well as ZFS.
the volume manager of your choice is laid out on top of the bare drive and is responsible for how the data is written onto the medium. if you ever used LVM or mdadm you will remember that you did not prepair the drives beforehand to put it in to raid volume or LVM volume. you just plug in the drive into system and used commands to create the raid/LVM volume on top. than you would create the mbr or gpt on the volume and create partition(s) on that. any older File systems are layered on top of the raw devices to make them usable, while BTRFS and ZFS are "File Systems" they incorporate some features that before only existed on specialty go-between media management modules like LVM or mdadm
so if you use any of this FS you do not need the go-between modules, all the features are right within the File System itself.
example :

with any older FS you had to go through several steps to prepare the drive for use.
even though you sometimes could do some of the steps in one swoop the steps where still there, just jumble up into single command.

i.e. when you issue the Format disk command you are telling the computer to perform this 3 basic steps in order.

1. create partition table. (prepare the disk for use by building a special database like structure in specific area of the disk)
2. create partition or partitions (using the database from step 1 , define and outline the area(s) of the disk to be used for data)

3. format the disk/partition as needed (this builds/define an address table of all bits on the disk into reference table with in the database in step 1)
(when you run format command on new empty disk , all 3 steps are performed in order as needed , when you ask to format partition only usually only step 3 is performed.)

BTRFS and ZFS use different schema and all the volume information is kept within internal metadata structures hence both of them can use disks directly, as is with no further preparation on your part.

Hope this was not overly detailed, but I though a more detailed explanation,even if you know most of it, might help someone with less experience, in the future.

So I have been doing something very similar except in my case I had a headless Win 7 machine using ArgusTV and Schedules Direct. The switch to TVHeadend is not to be taken lightly. Once you get the hang of it it's not hard set up but the real problem is the EPG data. To get Schedules Direct to work well I ended up having to use the 4.1.x test builds so I had xml utils with the tv_grab_sd_json for Schedules Direct. Even then TVHeadend cuts off the detailed show descriptions and ignores the repeat flag so you cannot set the DVR to new airings only. I ended up keeping Win 7 as a virtual machine to run ArgusTV.

I am not sure you can install TVHeadend successfully alongside OMV anyway since you will need 4.1 and don't think that installs on Wheezy. So you might need to have a VM for you DVR anyway.

Quote from ams123

So I have been doing something very similar except in my case I had a headless Win 7 machine using ArgusTV and Schedules Direct. The switch to TVHeadend is not to be taken lightly. Once you get the hang of it it's not hard set up but the real problem is the EPG data. To get Schedules Direct to work well I ended up having to use the 4.1.x test builds so I had xml utils with the tv_grab_sd_json for Schedules Direct. Even then TVHeadend cuts off the detailed show descriptions and ignores the repeat flag so you cannot set the DVR to new airings only. I ended up keeping Win 7 as a virtual machine to run ArgusTV.

I am not sure you can install TVHeadend successfully alongside OMV anyway since you will need 4.1 and don't think that installs on Wheezy. So you might need to have a VM for you DVR anyway.

I am not against DVR in VM , but if OP goes with OMV 3 it will be fine as it is on Jessie and have 4.1 or at least can install backport for it.

True but after having some issues myself with OMV 3 I would not push anyone in that direction. I would suggest the OP come up with a plan that allows for OMV2 or 3. IMHO 3 is still a beta product.

ok, in your case it really does not matter which FS you will use as you do not plan on using Raid, or LVM or anything special like that.

so first thing first, build out the hardware,

install OMV (I would definitely go with Version 3)
First thing to do after initial install is to login to WebUI and change Admin password
and UI time out settings so you can work.
also turn on and configure SSH so you can login into CLI as needed.
run all updates etc.
install your data drives if you did not do it before.
install omv-extras plugin.

using File system tab in OMV select each of your data drives and create filesystem on it.
omv v3 supports BTRFS so you will be able to choose it as FS for each drive.
OMV does not support any special configuration for BTRFS so you cannot create BTRFS raid setup or anything special, but a plain straightforward single drive format is supported.

using plugins tab, install SnapRaid and unionfilesystem plugins.
any other plugins as your fancy strikes,
if you have enough RAM and CPU I would install Virtual box as well. be aware though, if you do choose to install VB do it on it's own after all other plugins are setup and your data drives are ready for the data.
reason being, you can put your VM things on the data store rather than on SSD, which personally I prefer.

now once all of that installed (ignore VB for now)
use SnapRaid tab and configure the array. (remember that your biggest drive needs to be the Parity drive,
so your single 1TB will be your Parity and 2 500Gb will be your data) you will get 1TB of storage like this. if space is a commodity skip the snapraid for now and just run 3 drives as is until you can get a 2TB drive to add as parity snap raid and mergerfs can be added at any time even on filled disks with no problems.

no use the unionfilesystem tab and create a new pool using your data disk. give name to the pool (it will ask for it.)
if you skipped the snapraid for now, you can add all 3 of the drives to the pool.
if you use snapraid only pool the" data" disks , do not add parity disks to the pool.
NOTE: an FYI tip, when creating file systems, add label to the disk according to what you will be using them for.

i.e. I name my all data disks either D[##] (D+number of the disk according to the sequence I create them
) OR data## (same as above but using full word "data" )
P[##] or parity## etc.
the reason I add sequence to the parity drives is that snapraid can use multiple parity disks and this way I know what is which.
when all is done, add Shares using the pool drive (which will be created and mounted automatically for you by OMV)

since OMV mounts everything in "/media/<UUID>" you might want to create a links folder and symlink the pool mount with a friendly name there for future references, there is a plugin for that too.
now that you ready you can install the TVHeadend using CLI and configure it as you pleased.

now if you had a network tuner like silicondust makes you could just run a ubuntu VM and install headend inside VM. mounting NFS shares to record the data from it.
but a built-in tuner will not transfer to VM. maybe a good plan for the future upgrades.

may I make a suggestion, if you have a choice do not get untested tuners.
it maybe just me, but over the years I had so much issues with different tuners compatibility
that I just gave up on that idea.
I am planning to resurrect the setup some time in the future but A. using a network tuner, this way I am not tied to a specific machine, and B. all my research points to the Silicon dust home run tuners as the most comparable out there. everywhere you look SD-homerun is supported out of the box whether by Linux or Windows.

as for network traffic, I don't know, maybe if you use a good quality switch and split the load using vlans?
with my setup I can simply separate the tuners physically. my server has 2 nics and is located in the basement right next to Cable box. so I can do that. YMMV