As far as I'm aware, port mappings using --publish or -p are ignored when using host or macvlan network types.
Not a Synology issue, but rather a limitation of containers.
I believe you.
When I use --net=host and port mapping I get this error from the docker run command.
WARNING: Published ports are discarded when using host network mode
This is normal and doesn't matter because you specified the port mapping to allow those ports to reach the container.
1 Like
I can get to the welcome screen
click the Log In button (http://192.168.1.3:8189/auth/login)
login to my channels account
it then times out here http://172.17.0.2:8089/auth/confirm?code=<redacted>
The connection has timed out
The server at 172.17.0.2 is taking too long to respond.
log
2021/01/18 08:59:11.414710 [SYS] Starting Channels DVR v2021.01.15.1649 (linux-x86_64 pid:1) in /channels-dvr/data
2021/01/18 08:59:12.427880 [SYS] Started HTTP Server
2021/01/18 08:59:12.837598 [HDR] Found 0 devices
2021/01/18 08:59:12.865119 [ERR] Failed to refresh auth: missing oauth client
2021/01/18 08:59:12.866347 [SYS] Bonjour service running for dvr-a107c21ec09e.local. [172.17.0.2]
I guess you need to change the url back to correct IP and port and leave the /auth/confirm at the end
1 Like
Changing the url from
172.17.0.2:8089/auth/confirm?code=<redacted>
to
192.168.1.3:8189/auth/confirm?code=<redacted>
did it
Thank you both @racameron and @tmm1 for the help.
Got it running with my Xfinity TVE source and am testing recordings.
I have a lot more to learn about docker, but at least I have the incentive now.
Can't figure out why when I stop and start the Channels DVR docker container, Channels DVR keeps reverting to the release version 2021.01.15.1649 instead of the pre-release version 2021.01.18.1649 it was using when I stopped the container.
Container is using --volume /volume1/arkives/ChDockerDVR/config:/channels-dvr
ls -l /volume1/arkives/ChDockerDVR/config
total 12
d---------+ 2 root root 4096 Jan 18 08:58 2021.01.15.1649
d---------+ 2 root root 4096 Jan 18 09:30 2021.01.18.1649
d---------+ 5 root root 4096 Jan 18 15:51 data
lrwxrwxrwx+ 1 root root 15 Jan 18 22:02 latest -> 2021.01.18.1649
stat /volume1/arkives/ChDockerDVR/config/latest
File: '/volume1/arkives/ChDockerDVR/config/latest' -> '2021.01.18.1649'
Size: 15 Blocks: 0 IO Block: 4096 symbolic link
Device: fd00h/64768d Inode: 19505 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2021-01-18 22:02:25.678751224 -0800
Modify: 2021-01-18 22:02:24.674778457 -0800
Change: 2021-01-18 22:02:24.674778457 -0800
Birth: -
logs
2021/01/19 11:03:02.144266 [SYS] Created database snapshot: backup-20210119.110302
2021/01/19 11:03:18.812359 [SYS] Shutting down...
2021/01/19 11:03:18.814516 [DVR] Recording engine stopped.
2021/01/19 11:06:13.451648 [SYS] Starting Channels DVR v2021.01.15.1649 (linux-x86_64 pid:1) in /channels-dvr/data
2021/01/19 11:06:13.461574 [SYS] Started HTTP Server
2021/01/19 11:06:13.869565 [HDR] Found 0 devices
2021/01/19 11:06:14.694657 [DVR] Recording engine started in /shares/DVR
2021/01/19 11:06:14.785699 [SYS] Created database snapshot: backup-20210119.110614
2021/01/19 11:06:24.815896 [IDX] Pruned 266 expired airings from X-TVE in 104.873239ms.
Most likely a permissions issue. Another possibility could be SELinux policy differences.
In either case, your config changes don't seem to be persisting.
I don't know. Not sure how Channels DVR 'remembers' what version it was running.
I'm also running Channels DVR as a Synology package and stopping/starting that package doesn't exhibit the same behavior.
I do know if you do a fresh install it will grab the latest release version, but this isn't a fresh install. All the settings, guide data, imports, etc. are still there when I start the container.
Appears after starting the container, Channels DVR is changing the 'latest' link for some reason?
ls -l /volume1/arkives/ChDockerDVR/config
total 12
d---------+ 2 root root 4096 Jan 18 08:58 2021.01.15.1649
d---------+ 2 root root 4096 Jan 18 09:30 2021.01.18.1649
d---------+ 5 root root 4096 Jan 18 15:51 data
lrwxrwxrwx+ 1 root root 15 Jan 19 11:06 latest -> 2021.01.15.1649
This works, but is a kludge
ln -nsf 2021.01.18.1649 latest
curl -XPUT http://192.168.1.3:8189/updater/force/restart
2021/01/19 12:46:34.976183 [DVR] Recording engine stopped.
2021/01/19 12:46:36.535159 [SYS] Starting Channels DVR v2021.01.18.1649 (linux-x86_64 pid:1) in /channels-dvr/data
Decided to see what would happen if I removed all versions except for current pre-release 2021.01.19.1937 it's running
Did a database backup
Stopped the Channels DVR docker container
# cd /volume1/arkives/ChDockerDVR/config/
# ls -l
d---------+ 2 root root 4096 Jan 18 08:58 2021.01.15.1649
d---------+ 2 root root 4096 Jan 18 09:30 2021.01.18.1649
d---------+ 2 root root 4096 Jan 19 14:02 2021.01.19.1937
d---------+ 5 root root 4096 Jan 18 15:51 data
lrwxrwxrwx+ 1 root root 15 Jan 19 14:02 latest -> 2021.01.19.1937
removed older versions
# rm -r -v ./2021.01.18.1649
# rm -r -v ./2021.01.15.1649
# ls -l
d---------+ 2 root root 4096 Jan 19 14:02 2021.01.19.1937
d---------+ 5 root root 4096 Jan 18 15:51 data
lrwxrwxrwx+ 1 root root 15 Jan 19 14:02 latest -> 2021.01.19.1937
Started the Channels DVR docker container
Channels DVR downloads 2021.01.15.1649 and runs it
# ls -l
d---------+ 2 root root 4096 Jan 19 20:36 2021.01.15.1649
d---------+ 2 root root 4096 Jan 19 14:02 2021.01.19.1937
d---------+ 5 root root 4096 Jan 18 15:51 data
lrwxrwxrwx+ 1 root root 15 Jan 19 20:36 latest -> 2021.01.15.1649
My guess is that's baked into the script that runs in the docker container. Download the latest release version and run it.
Container log
channels-dvr-tve
date stream content
2021-01-20 04:35:54 stdout Installing Channels DVR..
2021-01-20 04:36:34 stdout Downloading Channels DVR 2021.01.15.1649 (linux-x86_64) to //channels-dvr......
2021-01-20 04:36:34 stdout Channels DVR has been downloaded.
2021-01-20 04:36:34 stdout Running Channels DVR..
No, because I use a container and have no issues when restarting the container.
I also:
- Do not use Docker, but rather Podman
- Have SELinux policies established and respected when mounting my Channels' directories as overlays
- Monitor the permissions on all directories invoked to ensure they align
FWIW, here's what I do on my DS1618+. I have a MACVLAN so all my containers can have their own IP address with ports for the router firewall using something like this: https://blog.oddbit.com/post/2018-03-12-using-docker-macvlan-networks/
(If you end up going this route I can give you my specific details if needed.)
docker pull fancybits/channels-dvr:tve
docker run --detach --network docker-net --ip=10.0.1.125 --mac-address 02:42:0a:00:02:7d --name=channels-dvr -e TZ=America/New_York --volume /volume1/channels/config:/channels-dvr --volume /volume1/channels/recordings:/shares/DVR --volume /volume1/channels/mylibrary:/mylibrary fancybits/channels-dvr:tve
It's been running like this for over a year without any issues. Support provided the egress domains for channels if you need for firewall.
Thanks.
I already created a user defined bridge network 'cdvr-net' that works fine for my purposes. I won't be using remote access.
My current docker run command is
docker run \
--detach \
--name=channels-dvr-tve \
--env TZ=America/Los_Angeles \
--network=cdvr-net \
-p 192.168.1.3:8189:8089/tcp \
--restart=on-failure:10 \
--volume "/volume1/arkives/ChDockerDVR/config:/channels-dvr" \
--volume "/volume1/arkives/ChDockerDVR/recordings:/shares/DVR" \
--volume "/volume1/arkives/testMovies:/shares/import/movie:ro" \
--volume "/volume1/arkives/testTV Shows:/shares/import/tv:ro" \
fancybits/channels-dvr:tveWell that was a long walk down an unfamiliar path to get here.
Something's not right with the docker container and permissions.
Directories and files are being created like a UMASK 777 was in place.
Do I need to pass a UID or UMASK somehow to the container run command?
The containers run.sh fails to find the excectuable file channel-dvr because of its perms.
#!/bin/sh
set -e
if [ ! -x /channels-dvr/latest/channels-dvr ]; then
echo Installing Channels DVR..
curl -f -s https://getchannels.com/dvr/setup.sh | DOWNLOAD_ONLY=1 sh
fi
cd /channels-dvr/data
echo Running Channels DVR..
exec ../latest/channels-dvr >> channels-dvr.log 2>&1
ls -l latest/channels-dvr
----------+ 1 root root 38749040 Jan 19 20:46 latest/channels-dvr
Once I chmod 755 latest/channels-dvr, it works fine.
@tmm1 it appears the setup.sh script run during install does set the execute bit on all files downloaded (latest release) during the initial install using 'chmod +x channels-dvr/$version/*'
release version 2021.01.15.1649
---x--x--x 1 root root 38736176 Jan 19 20:36 channels-dvr
---x--x--x 1 root root 22602264 Jan 19 20:36 comskip
---x--x--x 1 root root 79617272 Jan 19 20:36 ffmpeg
---x--x--x 1 root root 13673672 Jan 19 20:36 ffmpeg-dl
---x--x--x 1 root root 15375416 Jan 19 20:36 ffprobe
---x--x--x 1 root root 376 Jan 19 20:35 linux-x86_64.sha256
But, whatever is doing the pre-release update is not setting the execute bit on the pre-release version files that are downloaded.
pre-release version 2021.01.19.1937
----------+ 1 root root 38749040 Jan 19 20:46 channels-dvr
----------+ 1 root root 22602264 Jan 19 20:46 comskip
----------+ 1 root root 79617272 Jan 19 20:46 ffmpeg
----------+ 1 root root 13673672 Jan 19 20:46 ffmpeg-dl
----------+ 1 root root 15375416 Jan 19 20:46 ffprobe
----------+ 1 root root 376 Jan 19 20:46 linux-x86_64.sha256
----------+ 1 root root 15 Jan 19 20:46 prerelease
----------+ 1 root root 15 Jan 19 20:46 version
Hence, when the container is stopped and started running pre-release 2021.01.19.1937, the run.sh script fails to find /channels-dvr/latest/channels-dvr as an executable and redownloads the latest release 2021.01.15.1649 and runs it.
I did check the umask in the container and it's 0022. Any file I create within the container 'touch test.txt' has perms as expected, 644 for normal files. If I create a file in one of the volume mounts from within the container 'touch channels-dvr/test.txt' it's created with perms 000.
So, at this point, anytime I update to a new pre-release, I have to 'chmod +x channels-dvr/latest/*' (actually 'chmod +x channels-dvr/latest/channels-dvr' would work)..
1 Like
I'm about to remove docker from my system.
The only reason I installed it was to learn Docker (and running channels-dvr in Docker gave me the motivation).
If it doesn't work with channels-dvr, I'm done wasting my time learning Docker (and linux to understand Docker).
I understand the file system mounts and userspace swapping, but if I cannot maintain channels-dvr on it without jumping through hoops (chmod +x channels-dvr/latest/channels-dvr) everytime I update versions, then no point in using it.
Spent way too much time learning things about Docker and linux I shouldn't have to know (and will soon forget) to get to this point. Just another layer of complexity to deal with.
I know there are other ways to run a container, but I'm a Synology NAS user, not a linux/container guru. That's why I chose a Synology NAS. /soapbox
It was (somewhat) fun while it lasted.
1 Like
Got it working by changing the run.sh test parameter from -x to -f and committing changes to a new local image.
1 Like
The problem was my mapping --volume /volume1/arkives/ChDockerDVR/config:/channels-dvr
Since /volume1/arkives is a shared folder, it messed with the permissions.
I now use --volume /volume1/docker/channels-dvr:/channels-dvr and don't have the issue anymore.
3 Likes
I'm trying to learn how to install Channels in a docker container on my Synology, now that YouTubeTV seems to require that to authenticate, but I'm only able to get up to having the fancybits/channels-dvr:tve image in docker. I'm getting lost when it comes to launching it. I don't understand Docker and need a step-by-step.
Assuming the Synology just has /volume1/ and I'm simply going to have Channels saving recordings to /volume1/DVR/, how should I proceed?
I think I also read somewhere in the threads here that docker should be set to not auto-update to keep a Channels container working. Is that still true?
create directories
/volume1/docker/channels-dvr
/volume1/DVR
If you're using /volume1/DVR to record to, I recommend creating it as a shared folder.
After installing the Synology Docker package
SSH into your Synology and run this from the command line
sudo docker run --detach --name=channels-dvr-tve --env TZ=America/Los_Angeles -p 8189:8089 --restart=on-failure:10 --device /dev/dri:/dev/dri --volume /volume1/docker/channels-dvr:/channels-dvr --volume /volume1/DVR:/shares/DVR fancybits/channels-dvr:tve
You'll need to adjust the following
set to your time zone
--env TZ=America/Los_Angeles
set the port you want to access it on (mine is 8189)
-p 8189:8089
remove this if your Synology doesn't support hardware transcoding
--device /dev/dri:/dev/dri
If you leave that in and your Synology doesn't support hardware transcoding you'll get an error when you do the docker run coommand.
Then when you're picking the recording path in Channels DVR setup, you'll use shares/DVR
The thing to keep in mind is that ports and volume paths to the left of the colon : are for your Synology and things to the right are for the container.
You can always add import paths later using the Synology Docker GUI
I highly recommend learning how to SSH into your Synology.
However, in a pinch you can execute the docker run command using the Synology Task Manager.
Task Scheduler>Create>Scheduled Task>User-defined script
Set it up so you can manually run it once and then disable/delete the task.
Run as user root
Schedule to run on a future date and not repeat
Paste this line in the Task Settings>Run command>User-defined script box after modifying it for your port and timezone.
docker run --detach --name=channels-dvr-tve --env TZ=America/Los_Angeles -p 8189:8089 --restart=on-failure:10 --device /dev/dri:/dev/dri --volume /volume1/docker/channels-dvr:/channels-dvr --volume /volume1/DVR:/shares/DVR fancybits/channels-dvr:tve
Click OK to save it
Disable the task
Highlight the task and click the Run button from the menu above.
That will create and run the docker container same as doing it from the SSH command line.
1 Like