unofficial Docker Container for Record Engine

[demonrik]

Have created a very simple docker container which pulls the latest DVR record engine from SD servers when it starts.
Pull from docker hub here https://hub.docker.com/r/demonrik/hdhrdvr-docker
Source is https://www.github.com/demonrik/HDHR-DVR-docker

Example docker run command

Code: Select all

docker run -d --name dvr \
  --restart=unless-stopped \
  --network host \
  -v /path/to/hdhomerun/tempdata:/dvrdata \
  -v /path/to/hdhomerun/recordings:/dvrrec \
  demonrik/hdhrdvr-docker

Have tested on various linux installations, Qnap NAS, and Asustor NAS - no issues.
Synology NAS has no docker support for ARM based NAS, so haven't been able to test there as my Synology is ARM based , but suspect it should work.
Have a few more tweaks to make, but working sufficiently to share.

You will need 2 volumes you need to create or bind (recommended)

• /dvrrec recordings location
• /dvrdata Location to store the engine, config file and log of the script in the container

As you can see I use

Code: Select all

--network host

(note the double -)
This is very important for HDHomeRun system to ensure everything is on the same network.
If you run the container and it's log is showing it's not seeing devices - chances are you missed this.

Once the container is running you can changes the dvr.conf file in your dvrdata to adjust the RecordStreamsMax..
Don't change the RecordPath
Also would recommend to NOT change the Port unless you know what you're doing.
Important that the engine has opportunity to write to the dvr.conf at least for the first time so it updates the StorageID.. Once done, you can make the dvr.conf read only.

Todo Items

• Enable parameter to ignore beta releases
• Validate the dvr.conf before start to ensure not broken
• Logfile size management

[TBlankenheim]

Installed this on my UNRAID server and it looks to be functioning as expected.

I like the idea of automatically keeping the record engine current. The previous docker I was using required me to update the engine manually until the author of the docker container updated it. Sometimes that took a while.

I also like that the data directory is accessible external to the container.

Docker is the way to go!
Thank You!

[demonrik]

Installed this on my UNRAID server and it looks to be functioning as expected.

I like the idea of automatically keeping the record engine current. The previous docker I was using required me to update the engine manually until the author of the docker container updated it. Sometimes that took a while.

I also like that the data directory is accessible external to the container.

Docker is the way to go!
Thank You!

Glad you like.
Yeah I looked at others and came to conclusion that I needed to expose the conf, and having the container self update the record engine also makes sense. On latter I also wanted to avoid redistribution of the binaries from Silicondust.. so this made perfect sense.
A few tweaks to make as noted in OP.. but nothing that's critical.

[tredman]

Works perfectly. Thanks OP.

[TBlankenheim]

Glad you like.
Yeah I looked at others and came to conclusion that I needed to expose the conf, and having the container self update the record engine also makes sense. On latter I also wanted to avoid redistribution of the binaries from Silicondust.. so this made perfect sense.
A few tweaks to make as noted in OP.. but nothing that's critical.

I'm considering using this solution on my Synology DS918+ rather than your Synology SPK for DVR Record Engine (viewtopic.php?f=126&t=67044).

What would be the pros/cons of using the docker container?
Anything I should watch out for if I want to use the same share? Or should I create a new share?

I'm not really using the DVR Manager portion of the SPK package. I usually use your HDHR-DVRUI solution as a user interface (https://github.com/demonrik/HDHR-DVRUI).

Thanks!

[demonrik]

What would be the pros/cons of using the docker container?

Once I redo the SPK soon to remove the UI - they'll be more or less the same
Main Con against container is you need to install all the container stuff, and as mentioned some Synologys aren't supporting containers on ARM processors.
For me though one big Pro is I have a central manager for all docker enabled devices, and have moved almost everything on my NASes to containers, and from the central manager (portainer) I can push the container down where I want easily (Once I have the volumes ready of course). Working on seeing if I can build in redundancy next.

Anything I should watch out for if I want to use the same share? Or should I create a new share?

Permissions mostly.
With the UI right now it needs a wrapper to ensure the record engine is run as http user.
With the containers you can set what the PUID is on start or leave run to default which I think is usually root or admin on QNAP/Synology
So you SPK install might not be able to see some recordings from the container version.

[TBlankenheim]

Main Con against container is you need to install all the container stuff, and as mentioned some Synologys aren't supporting containers on ARM processors.

I have a Celeron based Synology so Docker is not and issue.

With the containers you can set what the PUID is on start or leave run to default which I think is usually root or admin on QNAP/Synology

I installed the Docker Container on my Synology and can confirm that the default user is root.

I'm still rather new to Docker Containers. Is there a way to pass in the PUID?

Thanks!

[demonrik]

I'm still rather new to Docker Containers. Is there a way to pass in the PUID?

Thanks!

Well, I'm still learning too
I believe you need to set them via environment vars if you can't use the user flag on docker run
e.g.

Code: Select all

docker run -e PUID=xxx -e PGID=yyy ....

Where xxx and yyy are the user UID and GID u want use
Newer docker also has -u uid:gid

Not sure if I have to handle or not in container

[TBlankenheim]

Well, I'm still learning too
I believe you need to set them via environment vars if you can't use the user flag on docker run
e.g.

Code: Select all

docker run -e PUID=xxx -e PGID=yyy ....

Where xxx and yyy are the user UID and GID u want use
Newer docker also has -u uid:gid

Not sure if I have to handle or not in container

No luck using the environment vars. Looks like you would have to handle that in the container.

The user flag (--user="UID:GID") works on my UNRAID server but I am still researching how to accomplish that on my Synology. I can pass in the environment vars using the DSM GUI, but they did not provide a way to pass in any extra docker run parameters using the GUI. Looks like Synology's implementation may support that parameter using the docker run command but probably not an ideal solution unless I can figure out a way to have the docker run command persist across updates and reboots.

When you redo the SPK are you planning to handle Record Engine updates using the same technique as your docker?

Thank You for all your work!

[Flamez]

Installed this on my UNRAID server and it looks to be functioning as expected.

I like the idea of automatically keeping the record engine current. The previous docker I was using required me to update the engine manually until the author of the docker container updated it. Sometimes that took a while.

I also like that the data directory is accessible external to the container.

Docker is the way to go!
Thank You!

You mind sharing your config for the unRaid docker? I have been looking for something like this.

Thank you.

Flamez

[TBlankenheim]

You mind sharing your config for the unRaid docker? I have been looking for something like this.

Thank you.

Flamez

This is the initial configuration that I used:

Code: Select all

Name: 			hdhrdvr-docker
Repository:		demonrik/hdhrdvr-docker
Network Type:		host
Console shell command:	Shell
Privileged:		Off

These are the Paths I created:

Code: Select all

Config Type:	Path
Name:		DVR Data
Container Path:	/dvrdata
Host Path:	/mnt/user/appdata/hdhrdvr-docker
Default Value:
Access Mode:	Read/Write
Description:	/dvrdata
Display:	Always
Required:	No
Password Mask:	No

Config Type:	Path
Name:		DVR Recordings
Container Path:	/dvrrec
Host Path:	/mnt/user/HDHomeRunDVR/
Default Value:
Access Mode:	Read/Write
Description:	/dvrrec
Display:	Always
Required:	No
Password Mask:	No

If you want the data, logs and recordings to be created as nobody:users, add the following to Extra Parameters (Advanced View). Otherwise all files will be created as root. Should not be a problem if all recordings will be managed by the SD UI.

Code: Select all

Extra Parameters:	--user="99:100"

I also added the following variables in case demonrik decides to support UID and GID as environment vars. Currently these variables have no effect.

Code: Select all

Config Type:	Variable
Name:		PUID
Key:		PUID
Value:		99
Description:	PUID

Config Type:	Variable
Name:		PGID
Key:		PGID
Value:		100
Description:	PGID

[Flamez]

Thank you! It worked just fine! I appreciate you sharing your config. Big thank you to demonrik for creating this docker!

[demonrik]

Sorry for delay in responding - being doing lots of investigations alongside the day job.

so a few things I'll change in next version (hopefully before end of week)
1. Create a default 'dvr' user in the container and run as that user, so not always running as root. (just better security wise)
2. Provide hooks to update that 'dvr' user with the PGID and PUID if provided like linuxserver.io containers do.. Some others use other env vars, but linuxserver.io seems to be the most consistent.

The only issue of course is permissions now have to be managed properly, and if the script can't delete the record engine because the admin set the UID/GID differently this run then I need to find a way to alert the admin to the problem.. Until I have that working I will keep from making the change.

In doing these changes will be able to run with or without the -user docker option depending on where you run it.

And on that note..
I checked into synology and qnap and sure enough their docker command lines DO support -user but they do not provide the hooks to enable it in their respective UIs so everything runs as admin/root by default.
there are a bunch of howtos online about how to get it to run as a different user/group but it's not persistent and doesn't survive a reboot.

The best method I've found so far is to do what Asustor does for their NASes..
Use off the shelf solution like Portainer
Here are links to how to enable for QNAP and Synology
Once installed you can invoke the user settings via portainer.
I can't confirm Synology - but I got it working on QNAP by create a new dvr user and group, and then in portainer (which was running on my Asustor) setting the user to the UID:GID of the user on the QNAP, e.g. 1002:1000. I couldn't use the username because it seems portainer looked at the local system, not the remote so specific UID:GID worked as it skipped the local checks.
Once I fixed the permissions in the folders for data & recordings all works as intended and is running as dvr user on the QNAP.

[TBlankenheim]

The best method I've found so far is to do what Asustor does for their NASes..
Use off the shelf solution like Portainer
Here are links to how to enable for QNAP and Synology
Once installed you can invoke the user settings via portainer.
I can't confirm Synology - but I got it working on QNAP by create a new dvr user and group, and then in portainer (which was running on my Asustor) setting the user to the UID:GID of the user on the QNAP, e.g. 1002:1000. I couldn't use the username because it seems portainer looked at the local system, not the remote so specific UID:GID worked as it skipped the local checks.
Once I fixed the permissions in the folders for data & recordings all works as intended and is running as dvr user on the QNAP.

Great information! Thanks!

I did get the Portainer implementation working on my Synology using the technique you described. I was just a little dense figuring out exactly how to set the UID:GID in Portainer, but I eventually figured it out.

Now if SD would provide a way to set the priority of the Record Engine in multi-engine environments, I would be an even Happier Camper!

[demonrik]

When you redo the SPK are you planning to handle Record Engine updates using the same technique as your docker?

Just released it
Working on this docker image next to update for user, etc., then full focus on DVRUI project