How-to: Use FreeBSD for recording and streaming HDHomeRun TV

FreeBSD with ZFS for Recording TV using HDHomeRun tuners

Disclaimer: I can't make any promises that any of the included information is correct, just that it appears to be working for me. I've had this setup for about 2 months now, recording TV for approximately 18 hours a day, generally two stations at a time since I record the news. The VM is also used for streaming the content after (or even as) it's recorded.

Part One -- Background:

This is an article I wrote up - I thought I'd put the sections in subsequent posts in the thread so it is organized and easier to follow. I'm not sure of anyone else who uses FreeBSD for recording TV using an HDHomeRun device - there are plenty using FreeNAS - but I hadn't seen any guidance specifically for FreeBSD, so I thought I should write some.

I'm using an HDHomeRun RECORD / DVR setup with 2x HDHomeRun Prime digital cable TV tuner boxes, which use cable cards from the cable company to tune channels (3 tuners each). The host RECORD system records and plays back MPEG-2 streams to anywhere on your LAN (or further if you want to blow holes in your external pf).

I had been using ZFS for a 4-drive pool in CentOS 7, and it had been working well for recording the TV, but Samba my network share sequential transfer speeds were crawling at 1.2 MB/s. I primarily use Windows networking in my house with domain controllers and all that, so SMB-compatibility is pretty important to me.

So Samba on CentOS 7 was painfully slow. I believe there must be some regressive code somewhere creating throughput issues. ZFS share functionality using sharesmb=on doesn't work in CentOS, which is a long-known bug that is unlikely to be resolved. That got me thinking I should switch. I knew ZFS was far more mature on FreeBSD, so I thought it'd be a good OS to try out. Although I had originally decided to leave CentOS for FreeBSD because I was hoping sharesmb=on would work - note: it doesn't, it only works properly on Solarish systems - I found that userland Samba throughput has been exponentially better on FreeBSD, it's more straightforward to make RC scripts than work with Systemd, and it has a lot of nice features I hadn't seen in Linux variants, so I decided to stay with it and have been using it ever since.

On my FreeBSD VM with Samba 4.5 connected to a Windows 2016 domain mounted in Windows to a Thinkpad T420 over a MoCA 2.0 double-bonded connection I was able to get over 100MB/s sequential transfer speeds in CrystalDiskMark. I am fairly certain that's the best throughput I've seen for Samba thus far, and I have tried a lot of distros. This is using the same configuration settings I used on CentOS, too, on the same network, with the same computers. It's literally been almost 100 times faster.

Oh, and the HDHomeRun TV recording software works great, too. ;)
Part two: Some stuff to make a Linux user feel a little more at home

you should totally blow past this part if you aren't a previous Linux transplant and/or you don't give AF about how your shell 'feels'.

However, if you are either of the above, there are some little things you might discover about FreeBSD differences being somewhat unnerving since you're probably used to things working a certain way. A lot of this can't be avoided, but for a few things that can, here's what you can do:

Install bash and (insert your preferred text editor - I use nano):
# pkg install
If you haven't run pkg yet you have to install it using this command - FreeBSD package manager isn't installed by default (wow, so customizable ;) )
# pkg install sudo bash nano

Change your shell to bash (obviously you can use any other shell here you like, bash just happens to be the most common for Linux users):
# chsh -s /usr/local/bin/bash

Then edit /home/local/.profile and /root/.profile for preferred editor (It's set up for vi like most Unix-ish OS. If you prefer to use nano or vim or emacs or pico or ee, this is how you set it as your user's default).

Include bash only if you prefer bash to sh. From what I understand it's backward-compatible with sh. Note: if you are running sh scripts you may wish to invoke $ sh rather than $ ./ to make absolutely sure. Also, remember bash uses export while sh uses setenv.

OK, enough of the training wheels...
Part three: ZFS array and essential system configuration files

For my setup, I started by creating a dual-vdev mirror configuration on four HGST 7k2000 drives - it's a good combination of speed and redundancy. Also, mirrored vdevs have a few other advantages: their scrub and resilvering speeds are much, much faster than raidz arrays. Plus, unlike raidz, they can also be expanded just by adding additional vdevs - pop in a couple more HDDs and add them to the pool and it keeps growing.

While general ZFS commands are beyond the scope of this post for now, I want to quickly mention the ZFS command for that type of array was:
# zpool create mirror ada1 ada2 mirror ada3 ada4 nameofpool
I like to mount it in the /mnt directory instead of root.
# zfs set mountpoint=/mnt/nameofpool nameofpool
This is important - read up on it before you make your pool: I've noticed ZFS has detected (and implemented) the proper ashift value on my FreeBSD VMs, but that might not always be the case. It's important because if it is improperly implemented it can adversely affect your disk throughput. Larger ashift is apparently OK, but you wouldn't want ashift=9 - for the old 512b sector drives - on an array that should be ashift=12 - for 4K sector drives. Please see this handbook page for more info:

If you are concerned about this (and you should be), especially if you have 4k block-size "advanced format" drives, be sure to set [I]vfs.zfs.min_auto_ashift[/I] ="12" in /boot/loader.conf If you Google ''ZFS ashift'' on the interwebs, there is a ton of information and discussion about the subject which will be transported to you through a series of tubes.

So, a few of the obligatory commands for maintaining FreeBSD are very similar to other Unix-ish systems. Try running this command on a new install:
# freebsd-update fetch install
It'll keep your system up-to-date. Then, now that your system is updated, let's install the files relevant to the project of making an HDHomeRun TV recording computer (or VM):
# pkg install \
samba47 \
krb5-115 \
plexmediaserver \
inotify-tools \
mrouted \
pimd \
Pkg is nice because there are different versions of the same software in the default repo. For Samba, I recommend using one-version-back from what's available, because I tried to use the latest version and it broke from a routine upgrade. If you're familiar with Samba you'll probably notice that 4.8 a the time of this writing is definitely bleeding-edge.

Kerberos newest version is probably fine, but since I stay a version back in Samba, I stay a version back in Kerberos, too.

I'm using Plex for dlna, which is a required protocol for the TV recording software: I had originally used minidlna, but I find Plex works better - less cases of stuttering, specifically when viewing on iOS devices (my girlfriend loves her iPad...).

Plex seems unnecessarily heavy for what it's used for in this scenario - I pretty much just use its dlna functionality - but it does seem to function quite a bit better. However, you still have to set it up. It's beyond the scope of this post, but just one thing important to remember when you're setting it up to configure your network under the allowed list of ip addresses, otherwise you'll get an endless 'searching for plex media server' the second time you log in to its web interface. The setting is located at:
Settings -> server -. Network -> List of IP addresses and networks that are allowed without auth
For example, I added so any computer on my local subnet can access the plex web menu.

Now, here are the two most often manipulated system configuration files, shown through real-world examples. In my examples, there are lots of # comments - if you don't want to use them, just don't add them - but if you can decide to include them since they can be useful for trying different things out.

The first big one is /boot/loader.conf:
# -------- For uPnP ------- #
# ---- For NTFS-3G -------- #
fuse_load="YES" #Only need if planning on mounting NTFS drives
# ------- ZFS flags ------- #
#zfs_load="YES" # Used for booting from ZFS pool
#vfs.zfs.prefetch_disable=1 # Use if you have 4GB mem or less
#vfs.zfs.arc_max="256M" # Use if you want to limit your ARC usage
#vfs.zfs.vdev.cache.size="64M" # Use if you want to limit your cache size
And the other is /etc/rc.conf:
# ------- ZFS Array ------- #

# -------- Network -------- #<br>
# ---------- IPv4 --------- #<br>
ifconfig_vmx0="inet netmask"
#ifconfig_em0="inet netmask"

# ------ Kill IPv6 -------- #

# ----- Enable IPv6 ------- #
#ifconfig_vmx0_ipv6="inet6 accept_rtadv"
#ifconfig_em0_ipv6="inet6 accept_rtadv"

# ----- VMWare Devs ---- #

# ------- Services -------- #
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
#winbindd_enable may or may not necessary for your version of samba for domain membership
Please look up any of these flags before you opt to use them, the man pages in FreeBSD are extraordinary and I'm sure there are lots of references and discussion about each one on the internets.

So again, in my particular .conf files there are a lot of flags which are extraneous that I comment/uncomment (turn on/off) using # when I want to troubleshoot my configuration easily. For example, I have settings for mrouted, pimd and ipv6. mrouted and pimd are for multicast, so I have those turned on for better playback. I turned off ipv6 when I thought it was making it difficult to secure domain membership.

There's also a lot of flags I included that are VMWare-specific, too, so if you're using bare metal or a different hypervisor, obviously you'll want to ignore those. If you ARE using VMWare-any-hypervisor (ESXi, Workstation, Fusion, etc.) and haven't already, grab open-vm-tools-nox11 through pkg.
Part four: The actual HDHomeRun TV recording software

The HDHomeRun RECORD software can be downloaded on the manufacturer's forum:

That thread also explains how to use the HDHomeRun RECORD service in the most straightforward way, which summarized is as follows:

Download it to your media folder with wget or curl, make it executable, create a quick config file and then run it.

# cd /path/for/recordings

# wget

# chmod u+x hdhomerun_record_freebsd

# echo 'RecordPath=/path/for/recordings/' > hdhomerun.conf

# sh hdhomerun_record_freebsd start

That's really all there is to that portion if that's all you want there to be. However, you might want playback as well as recording, so let's start plexmediaserver:
# service plexmediaserver onestart

Note: You won't have to do this if you've restarted your computer after adding plexmediaserver_enable="YES" to /etc/rc.conf

If you look at your network in a Windows Explorer you should see Plex Media Server under "Media Devices"

Now, here's the cool thing: That command, # service plexmediaserver onestart was invoking a service - which you can place in to your /etc/rc.conf to load at startup by editing the file or placing it there with the sysrc plexmediaserver_enable=YES command, running echo 'plexmediaserver_enable="YES"' >> /etc/rc.conf etc. - all sorts of ways, pick a favorite, or just use them all at different times depending on how you feel like me.

Now, if you want to have a service for the HDHomeRun RECORD service, I put one together in a pinch by renaming the hdhomerun_record_freebsd file we downloaded earlier to simply hdhomerun_record, copying it to /usr/local/sbin/ and creating the following script named /usr/local/etc/rc.d/hdhomerun_record:
# PROVIDE: hdhomerun_record
# KEYWORD: stop
# Add the following line to /etc/rc.conf[.local] to enable RECORD:
# hdhomerun_record_enable="YES"

. /etc/rc.subr<br>


load_rc_config $name


command_args="start foreground --conf=/usr/local/etc/hdhomerun.conf"

run_rc_command "$1"
Now I can run the program anywhere since I copied hdhomerun_record to a location in the $PATH, but more importantly, the script allows me to stop and start by invoking the basic service commands, and also start the service on boot in /etc/rc.conf using hdhomerun_record_enable="YES"

Here's an example of it in use:
# service hdhomerun_record status
hdhomerun_record is running as pid 637.
And then just check the status by running the command (not as a service) in any location (for example, /mnt/tank):
# hdhomerun_record status
HDHomeRun RECORD running
Also, don't forget to copy hdhomerun.conf with the correct path you want to record to in it to /usr/local/etc/ and add hdhomerun_record_enable="YES" to /etc/rc.conf so your computer will start the record service on boot.

Now go to your HDHomeRun Setup program that you're using for configuring the HDHomeRun boxes on your network (In my case it's on a computer running Windows 10 under my TV) and select "record to NAS", apply, and save the settings. If the FreeBSD computer doesn't show up in the setup program, don't worry - it should still work. I got the icon to appear using pimd, mrouted and plexmediaserver, but it's not necessary so long as your RECORD service is running on the recording computer - remember, you can check it by running:
# hdhomerun_record status
Last edited:
Part five: Simple file share using Samba

I had to find something to put here because I'm assuming most people won't be joining their FreeBSD TV recording computer to a domain, but would still like to have a network share for transferring files from other computers, copying recordings to remote media, etc. I haven't set up a non-domain-member Samba share in ages, so instead of trying to wing-it without any real-world examples of my own, I found a promising-looking thread that should be of use to those who don't want to take the perilous plunge into using FreeBSD for Windows domain membership...

If you don't want to deal with Samba (and I can't blame you), you could always just use FileZilla or SCP, etc. for copying files across the network, and view your videos in Plex (which we installed earlier for its dlna capabilities, but it has a lot more...).

If you DO want to wade into the waters of frisky FreeBSD Windows Domain fornication, please read on ... (!) I've got something special with your name on it ...
Part six: Joining the TV recording computer to a domain

OK, so domain membership is quite a bit more involved. Here are the configuration files that are necessary for getting it working properly:

This does not include files required to be edited to log in to FreeBSD as a domain user - I've decided that is beyond the scope of this article. If you would like to use domain users on your new FreeBSD install, here's a brief site that covers a lot of bases and is very easy to follow:

Note: The version he used in that guide is older than 4.6. There was a syntax change in smb4.conf for v4.6 and newer that was requires re-writing part of the configuration for domain members - An example of the changes are things like winbind nss info = rfc2307 instead of unix_nss_info = yes

I'm about to show you all my configuration files for my working system for you to reference, but you will almost certainly need more in-depth info for attempting domain membership with Samba. Please familiarize yourself with the definitive guide at the official Samba wiki - either before or after trying the config examples (again - trust me, you'll need it):

OK, let's start with something easy and straightforward. Run # getent hosts - does it return something like this?:
Code:         localhost TVRECORDER

If it doesn't, make /etc/hosts look just like that. IPV6 additions are presumably fine (I've had issues with them and given up, but theoretically they should work, grumble) - I would assume you would only want to have one for ::1 localhost and the IPV6 address of your computer with fully-qualified domain name first and hostname second (just like it is for IPV4). Repeat after me:

"Samba is picky."

Keep that in mind and you might do just fine.

Now let's do time, which must be synchronized using ntp. Before you do that, though, check your hardware clock time (in BIOS), OS system time (in FreeBSD it's date, host time if you are running a VM (also known as 'hypervisor time') e.g. go look at your ESXi web client and make sure the time is right. The default maximum time difference fudge you can have is five minutes, so it's important to get all your swatches synchronized.

Once that's done, invoke # pkg install ntp to get the package, and edit /etc/ntp.conf to look something like this (source: samba wiki):
# Local clock. Note that is not the "localhost" address!
fudge stratum 10

# Where to retrieve the time from
server    iburst prefer
server    iburst

driftfile /var/lib/ntp/ntp.drift
logfile   /var/log/ntp

# Access control
# Default restriction: Disallow everything
restrict default ignore

# No restrictions for "localhost"

# Enable the time sources only to only provide time to this host
restrict    mask    nomodify notrap nopeer noquery
restrict    mask    nomodify notrap nopeer noquery
Where and are your domain controllers' IP addresses, respectively. If you only have one DC, you don't need two lines - just one for each one you have.

Run # service ntpd start (and # sysrc ntpd_enable=YES) and then check if it's working properly by invoking # ntpq -np. Here's an example of my output:
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================     .LOCL.          10 l  20h   64    0    0.000    0.000   0.000
*    3 u  233 1024  377    0.835   -5.978  22.238     .LOCL.           1 u   36 1024  377    0.258  40386.2 109.796
You can see I need to tighten up my ship a bit but it's still working (thank god). NTP issues have been (one of) the bane(s) of my domain's existence. You'll ideally have one that looks better than mine. If you're having issues with NTP in Windows Server, this article can be helpful (get ready, it's pretty complicated):

Then, I'd go on to kerberos. If you didn't install krb5-115 (or newer version) earlier, grab it now through pkg and edit /etc/krb5.conf to look like this (source: samba wiki):
     default_realm = YOURDOMAINNAME.COM
     dns_lookup_realm = false
     dns_lookup_kdc = true

That's all you need, or want, to have in it. Be sure to capitalize the domain name, too.

OK. So, presuming the prior requisite configurations are done properly, let's try joining the domain. Invoke:
# kinit administrator
administrator@YOURDOMAINNAME.COM's Password:
and that's it. Note: If you see errors regarding clock skew, that means your time is not correctly configured somewhere among the ever-so-many places it could be.

Now check to see if the process worked by invoking:
# klist
Credentials cache: FILE:/tmp/krb5cc_0
        Principal: administrator@WEBTOOL.SPACE

  Issued                Expires               Principal
May 28 21:27:21 2018  May 29 07:26:41 2018  krbtgt/YOURDOMAINNAME.COM@YOURDOMAINNAME.COM
And that, my friend, is your keytab file. (If you want to delete it to start over, etc. the command is kdestroy).

It allows you to authenticate YOURDOMAINNAME\administrator on the domain by invoking:
# net ads join -k
Using short domain name -- YOURDOMAINNAME
Joined 'TVRECORDER' to dns domain ''
Which should allow you to confirm that administrator is joined by invoking:
# net ads status

Which will return a slough of information, starting with something like this:
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: computer
distinguishedName: CN=TVRECORDER,CN=Computers,DC=yourdomainname,DC=com
instanceType: 4
whenCreated: 20180527091823.0Z
whenChanged: 20180529043207.0Z
uSNCreated: 29176
uSNChanged: 43014
-------------- Security Descriptor (revision: 1, type: 0x8c14)
owner SID: S-1-5-21-4216452045-2814096665-3585076981-512
group SID: S-1-5-21-4216452045-2814096665-3585076981-512
------- (system) ACL (revision: 4, size: 120, number of ACEs: 2)
------- ACE (type: 0x07, flags: 0x5a, size: 0x38, mask: 0x20, object flags: 0x3)
access SID:  S-1-1-0
access type: AUDIT OBJECT
Object GUID: f30e3bbe-9ff0-11d1-b603-0000f80367c1 (LDAP attribute: "gPLink")
Object GUID: bf967aa5-0de6-11d0-a285-00aa003049e2 (LDAP attribute: "organizationalUnit")
. . .

How about /etc/nsswitch.conf now, huh? It's really easy, just change groups: compat to groups: files winbind and passwd: compat to passwd: files winbind - you can do this at any time, whether you're joined to the domain or not, no need to reset any services or anything. It's probably the easiest thing to configure this side of /etc/hosts in this whole mess.

OK - so that's working. Now, on to the actual samba configuration. Easy stuff, right?

So here's my samba config - comments in samba are written with ; rather than # - it's located at /usr/local/etc/smb4.conf:
netbios name = TVRECORDER
security = ADS
client use spnego = yes
client signing = yes
server signing = yes
client ntlmv2 auth = yes
encrypt passwords = yes

log file = /var/log/samba4/%m.log
log level = 1

idmap config * : backend = tdb
idmap config * : range = 3000-7999

idmap config YOURDOMAINNAME : backend = ad
idmap config YOURDOMAINNAME : schema_mode = rfc2307
idmap config YOURDOMAINNAME : range = 10000-999999
idmap config YOURDOMAINNAME : unix_nss_info = yes
idmap config YOURDOMAINNAME : unix_primary_group = yes

;winbind use default domain = yes
winbind enum users = yes
winbind enum groups = yes
winbind offline logon = yes
winbind nested groups = yes
winbind refresh tickets = yes
winbind nss info = rfc2307

;Some syntax from prior to Samba 4.6:
;winbind nss info = template
;template shell = /bin/bash
;template homedir = /home/%D/%U

comment = a place for storing misc videos
path = /mnt/pool/videos
write list = @"YOURDOMAINNAME\domain admins"
read list = @"YOURDOMAINNAME\domain users"
writable = yes
browsable = yes
read only = no
guest ok = no
public = no
create mask = 0775
directory mask = 0775

comment = recordings from HDHomeRun box(es)
path = /mnt/pool/hdhomerun
write list = @"YOURDOMAINNAME\domain admins"
read list = @"YOURDOMAINNAME\domain users"
writable = yes
browsable = yes
read only = no
guest ok = no
public = no
create mask = 0775
directory mask = 0775
You can omit that whole part under realm = to the blank space - I included that for added security, it's the first thing I would scrutinize if you are having any trouble with connecting as a domain user. Well, maybe after checking /etc/krb5.conf and /etc/ntp.conf, restarting ntpd and checking to make sure the times are all synchronized on your domain controllers, members, hosts, and hardware clock (this is very important and often overlooked).

Also, note that rid backend is easier to get working properly than ad. Read up on the different backend types on the samba wiki page I referenced earlier in this section.

Check your winbind access to the domain by running:
wbinfo -u

Do you see stuff like:
?? if so, that's good. Now /etc/nsswitch.conf controls the ability to query the domain controller for users (the passwd line) and groups (the group line) using winbind (which you added to the end of the line for each, respectively). So try:
# getent passwd

And you should see a list of all the local users first (the files portion) and domain users at the end (the winbind portion):
.... truncated ....
dlna:*:933:933:DLNA Daemon:/nonexistent:/usr/sbin/nologin
git_daemon:*:964:964:git daemon:/nonexistent:/usr/sbin/nologin
cyrus:*:60:60:the cyrus mail server:/nonexistent:/usr/sbin/nologin
messagebus:*:556:556:D-BUS Daemon User:/nonexistent:/usr/sbin/nologin
plex:*:972:972:Plex Media Server:/nonexistent:/usr/sbin/nologin
YOURDOMAINNAME\avery:*:10000:0:Avery Freeman:/home/webtool/avery:/bin/bash

Same goes (presumably) for # getent group - if it doesn't work, something is wrong. Try rid backend if you're using ad.

One caveat about the shares in my configuration: The unix permissions underneath these shares must be 777 for domain admins to manipulate them, which in theory could be problematic since anyone can change them, even guests -- IF they're logged into the server as a Unix user. BUT, domain guests are prevented from accessing the share from the network due to guest browsing = no. Domain users are allowed to view the share (which you could easily change), and only domain admins are allowed to make changes.

This means, even if the underlying unix permissions are extremely permissive, it doesn't matter because connecting to the share through Samba as a unix user is not supported. Samba is for Windows networking, it has no idea how to handle unix users. Therefore, the thinking goes, the unix permissions don't really matter (except for allowing changes to be made by domain admins).

There's a better way to get Windows ACLs and unix permissions settings working together in tandem, but nobody's going to be logging in directly to my FreeBSD VM, so this method works fine for me without being too complicated. I came across another other site which describes how to do it properly but I haven't had the patience to sit with it yet:

OK. So that concludes the six-part series on how to set up an HDHomeRun TV recording computer! Hope you enjoyed it as much as I did.
Install bash and (insert your preferred text editor - I use nano)

(Preamble: this is totally uninformative reply on my behalf, and not even a critique on your excellent & thorouhgly useful How-To. I shall be putting it to use soon-ish, as I have a HDHomeRun box arriving to my doorstep any moment now)

Why would you abuse yourself with bash AND nano? That's borderline sadomasochism. The tcsh (though not default) shell & ee included in base FreeBSD XX.X-WHATEVER, do everything you need. I don't mean to knock bash, it is a very good shell...but nano?! Appart from the keyboard shortcuts being slightly different to ee, or vice versa, is pretty much exactly the same.

(I won't touch vi due to my bias wishing it to DIAF)
(Preamble: this is totally uninformative reply on my behalf, and not even a critique on your excellent & thorouhgly useful How-To. I shall be putting it to use soon-ish, as I have a HDHomeRun box arriving to my doorstep any moment now)

Why would you abuse yourself with bash AND nano? That's borderline sadomasochism. The tcsh (though not default) shell & ee included in base FreeBSD XX.X-WHATEVER, do everything you need. I don't mean to knock bash, it is a very good shell...but nano?! Appart from the keyboard shortcuts being slightly different to ee, or vice versa, is pretty much exactly the same.

(I won't touch vi due to my bias wishing it to DIAF)

Hey, sorry, I haven't been around for a while.

I, like most people my age (I'm assuming), got started in *NIX on Ubuntu and they are the default editor and shell. So I'm just more used to them.

I've noticed nano is less irritating to use on FreeBSD using -w (--nowrap) flag. It doesn't have word wrap enabled by default on a lot of other OS I've used it.

I'm OK with vim, but vi can be buggy depending on the OS (SmartOS, anyone?) so I try to avoid it unless I absolutely have to use it.

About this guide, the only thing that is really necessary is the HDHomeRun RECORD section (#4?). All the other stuff is fluff. I'm not sure if the dlna requirement was once required and removed in later versions of the RECORD software, or if I was just confused about it ever being required at all.

I've since moved to running HDHomeRun RECORD on FreeBSD using an OmniOS NFS share for storage mounted in fstab. In OmniOS, zfs sharenfs=on dataset actually works, not to mention zfs sharesmb=on dataset and domain membership without having to use Samba. Has saved me decades of headaches.

I've been Samba-free for a year now, and I won't ever go back.

Oh, one last little thing, is your friend.
How much of these instructions would apply if I installed a DVB-S2 card such as one of these

in my system?
How much of these instructions would apply if I installed a DVB-S2 card such as one of these

in my system?

I'm really not sure. It might be compatible with Plex DVR, I don't think it'll be compatible with HDHR DVR though, since it's a proprietary program for HDHomeRun devices.