Yeah, the authentication needed for Channels does not work with bridge networks. You need to use a host or macvlan type of network.
It may be Synology's implementation in their Docker package.
I installed their latest version available.
If I use either -p 192.168.1.3:8189:8089/tcp or -p 8189:8089/tcp without --net=host it uses the docker bridge network 172.17.0.0/16.
If I include --net=host -p 8189:8089/tcp the Synology Docker display shows the port binding for the container, but Channels DVR fails to start with error [ERR] Could not start server: listen tcp :8089: bind: address already in use
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]
1 Like
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