Linux Setup (Advanced)

[nickk]

The following instructions are for manual install and configuration of the HDHomeRun RECORD engine on a Linux machine. These instructions are intended for experienced users who want to experiment.

1) Create a folder for recordings.

2) Download the latest HDHomeRun RECORD for Linux release.
http://download.silicondust.com/hdhomer ... cord_linux
If are you are using FreeBSD (including FreeNAS), then download the FreeBSD version:
http://download.silicondust.com/hdhomer ... rd_freebsd
Copy to the recordings folder and rename "hdhomerun_record".
chmod +x hdhomerun_record

3) Create configuration file hdhomerun.conf
Create a configuration file hdhomerun.conf in the recordings folder. Add the line:
RecordPath=<full Linux path to recordings folder>

4) Start the HDHomeRun RECORD engine:
./hdhomerun_record start
./hdhomerun_record status

To start from a different directory:
/<path to recording folder>/hdhomerun_record start --conf /<path to recording folder>/hdhomerun.conf
/<path to recording folder>/hdhomerun_record status

Error "Permission denied" - run "chmod +x hdhomerun_record" to make the file executable.

5) Check the log file.
The progress release builds of the record engine generate detailed log files by default. The log files are placed in the HDHomeRun directory and are named YYYYMMDD.log (UTC time). Note that all timestamps in the log files are in UTC time, not local time.

No log file - this usually means the record engine was not able to find the config file, was not able to find RecordPath in the config file, or the path specified doesn't exist.

Getting help:
IRC channel: http://webchat.freenode.net/?channels=hdhomerun
Forum: Create a new thread - include the DeviceID of your HDHomeRun and a description of the problem/symptom.

[dartrunner]

How do I auto start the HDHomeRun RECORD for Linux when Ubuntu server reboots?

[ssyspro]

Been a long time since I set mine up but doing a search on google for hdhomerun_record.service should have results for a few systemd examples.

I believe that a package has been created by another user for deb based systems like ubuntu, I have not tried it but here is the forum link if you would like to. viewtopic.php?t=65560

[averyfreeman]

How do I auto start the HDHomeRun RECORD for Linux when Ubuntu server reboots?

Hi,

Sorry for reviving the necrothread but hopefully this will help someone who stumbles upon it like me -

You would want to create a systemd.service unit file to have systemd run the record executable as a service in the background and start at boot. It's pretty easy to use:

Code: Select all

# systemctl enable hdhomerun-record.service

would start it up at boot. You can replace 'enable' with 'start' to start it manually. Same thing with 'stop', and 'status'.

Creating the unit file is a little more involved, but this document explains it really well:

https://access.redhat.com/documentation ... unit_files

I know you use Ubuntu, but this RedHat document explains it better than the Ubuntu documentation does and they both work the same way.

[averyfreeman]

https://github.com/garybuhrmaster/packa ... rd.service

Pretty good example

[gtb]

Pretty good example

With the usual caveat that your mileage *will* vary (over the years I have created enough init, launchd, system management facility, systemd scripts/configurations to know that examples should be evaluated, and one should sort of expect to need to modify it for your unique environment (although in this case, that unit file may be >98% exactly what you need, since it is intended to be used with the record engine in modern Linux systems)).

And (the usual caveat I always try to remember to add), at some point SD will likely provide formal packages for the *major* NAS and Linux/Unix distributions which may completely change the approaches necessary (I would expect allowing enabling autostart will be included in the packages). It should be noted that some (especially) NAS devices makes stable autostart complex (read only file systems that are replaced from flash at every boot, and the overlay is different for each vendor) such that there is no way for a single approach to work everywhere, and the vendors often change things are firmware updates to invalidate existing approaches. Got to love standards (and everyone having a different one).

[averyfreeman]

Pretty good example

With the usual caveat that your mileage *will* vary (over the years I have created enough init, launchd, system management facility, systemd scripts/configurations to know that examples should be evaluated, and one should sort of expect to need to modify it for your unique environment (although in this case, that unit file may be >98% exactly what you need, since it is intended to be used with the record engine in modern Linux systems)).

And (the usual caveat I always try to remember to add), at some point SD will likely provide formal packages for the *major* NAS and Linux/Unix distributions which may completely change the approaches necessary (I would expect allowing enabling autostart will be included in the packages). It should be noted that some (especially) NAS devices makes stable autostart complex (read only file systems that are replaced from flash at every boot, and the overlay is different for each vendor) such that there is no way for a single approach to work everywhere, and the vendors often change things are firmware updates to invalidate existing approaches. Got to love standards (and everyone having a different one).

Yeah, undoubtedly why they only include installer scripts for the easiest-to-use OS like NAS, and would be spending all their time supporting different distros if they tried to make them for ALL of them

I noticed when I set up RECORD on Fedora 27 it saw my MiniDLNA instance like a NAS and had an installer package that just required ssh root access and smbd to be available. On CentOS it didn't even see the device, but it worked anyway if the RECORD service was started. Same with FreeBSD. I ended up not using Fedora because of how often the packages are updated (thought it was too bleeding-edge) but I suspect if I had just gone with it it may have been a lot easier than what I've gone through to get where I am now ...

[bqq100]

Is 20171013beta1 still the latest version for RECORD for Linux? If not, is there an new download link for the updated version? If it is the latest version are there any plans for an update in the near future?

Thanks!

[Ken.F]

Is 20171013beta1 still the latest version for RECORD for Linux? If not, is there an new download link for the updated version? If it is the latest version are there any plans for an update in the near future?

Thanks!

The download links in the first post in this thread always link to the latest version. Currently it is 20180418.

You may want to subscribe to the changelog thread so you will be notified of updates.
viewtopic.php?f=126&t=32339

[bqq100]

Is 20171013beta1 still the latest version for RECORD for Linux? If not, is there an new download link for the updated version? If it is the latest version are there any plans for an update in the near future?

Thanks!

The download links in the first post in this thread always link to the latest version. Currently it is 20180418.

You may want to subscribe to the changelog thread so you will be notified of updates.
viewtopic.php?f=126&t=32339

Weird, I downloaded from the link yesterday, dropped it onto my server, and restarted the service but it was still showing the old version number.

And thanks for the link to the changelog thread, definitely worth subscribing to!

[bqq100]

Is 20171013beta1 still the latest version for RECORD for Linux? If not, is there an new download link for the updated version? If it is the latest version are there any plans for an update in the near future?

Thanks!

The download links in the first post in this thread always link to the latest version. Currently it is 20180418.

You may want to subscribe to the changelog thread so you will be notified of updates.
viewtopic.php?f=126&t=32339

Ah, looks like when I restarted the service it couldn't overwrite the existing /tmp/hdhomerun_record_x64 file so it continued to run the old one. I manually cleared it out and restarted the service again and it is running the updated version now.

[Ratomas]

After installing on Ubuntu 18.04 and setting up RecordPath, I am getting "Unable to play channel Protocol error". The log just shows


20180730-03:10:37 Recording: discover on 192.168.0.255
20180730-03:10:37 Recording: discover response from 132824FA: lineup url = http://192.168.0.31:80/lineup.json
20180730-03:10:37 Recorded: recorded sync to api.hdhomerun.com
20180730-03:10:37 Recording: event download from api.hdhomerun.com
20180730-03:10:37 System: server time = Mon Jul 30 03:10:37 2018 (correction of 0s)
20180730-03:10:37 Recording: event download success
20180730-03:10:37 Recording: disk space available = 911GB
20180730-03:10:37 Recording: current time = Mon Jul 30 03:10:37 2018 (correction of 0s)
20180730-03:10:37 Recording: no timer events planned
20180730-03:10:37 Recorded: recorded sync success
20180730-03:10:53 Recording: starting new file Live channel 548 d0fc85d2
20180730-03:10:53 Recording: sending request to 132824FA at 192.168.0.31 for Live channel 548 d0fc85d2
20180730-03:10:58 Recording: stream from 132824FA closed - retrying Live channel 548 d0fc85d2
20180730-03:10:59 Recording: no tuners available to record Live channel 548 d0fc85d2
20180730-03:10:59 Playback: Live channel 548 failed to start: (null)
20180730-03:11:09 Recording: stop Live channel 548 d0fc85d2 (result = 0x0000)

[IllMethods]

Just wondering how many variables I can change in the config?

In my hdhomerun.conf I only have these two, one was put there by record itself

RecordPath=/media-server/ramdisk/HdHomeRun

StorageID=281490fc-8fba-c7f1-3564-0cb2c040b448

What I was wondering is if I could keep the live tv part in the Ram Disk, but store the library elsewhere...

[signcarver]

Only other real option other than additional paths added to RecordPath (for playback only, not record as it records in first) would be Port=# where # is the port number to use to ensure it always uses the same port when it starts.

What purpose do you want to use the RAM disk for live? You might try to make the Live folder as a link to the RAM disk. In the past, I have had good luck using such links for archive folders on other machines, but one should restart the engine after major archive moves as the reason "remote" storage isn't "allowed" is there can be some issues in being notified of changes but I have never tried to link to a RAM disk typically as such wouldn't have enough space. I would suggest at least 16GB to allow nearly 2 full movies, otherwise it might run into some problems depending on number of clients and how long the show is.