Channels on Docker speed bump

Channels DVR Server
#1

So just subscribed and grabbed the Docker contained based on the instructions on the site. The only part of the docker command I left off was --device /dev/dri:/dev/dri since my Linux box doesn’t have that device.

docker run \
    --detach \
    --name=channels-dvr \
    --net=host \
    --restart=unless-stopped \
    --volume /var/lib/media/tv/config:/channels-dvr \
    --volume /var/lib/media/tv/recordings:/shares/DVR \
    fancybits/channels-dvr:latest

I went to the Channels app on my AppleTV and clicked Login to Remote DVR. It sent me to a URL on my network ending in /auth which redirected me back to the Channels DVR page telling me I was subscribed but didn’t have Channels installed. While I appreciate the “simplified” approach it left me without much info.

Sooooo I dug… I found data/channels-dvr.log which had the following:

2017/11/19 02:01:03 [SYS] Starting Channels DVR v2017.11.16.0140 (linux-x86_64) in /channels-dvr/data
2017/11/19 02:01:03 [HDR] Found 1 devices
2017/11/19 02:01:03 [ERR] Failed to refresh auth: missing oauth client
2017/11/19 02:01:04 [SYS] Started HTTP Server
2017/11/19 02:01:04 [SYS] Bonjour service running for dvr-mcelwain.local. [172.18.0.1 192.168.1.4]

I pinged dvr-mcelwain.local. and immediately found it was returning back 172.18.0.1 which is Docker’s private network. So a recommendation would be to let the channels-dvr take an environment variable that specifies the IP address to be used would be a good improvement. That way the docker container could be started with -e CHANNELS_IP=192.168.1.4 and it’d serve up the right address.

Using netstat I figured out it was listening on port 8089 so I went to http://192.168.1.4:8089 which got me to the setup page.

Once I went through the setup (it was downloading listings) process I tried to repeat the above steps and the Channels DVR redirect told me I needed to go to http://dvr-mcelwain.local.:8089 so I’m not sure if I didn’t wait long enough (it was enough time to search the forums for anyone with a similar behavior and find none and write up most of this post).

#2

FYI /dev/dri is used for hardware video transcoding using the i915 kernel module.

Can you provide the output of x.x.x.x:8089/system/network

I would like to know the name of the interface with that private IP assigned. Since we are using -net=host I wouldn’t expect any docker private ips assigned.

#3

The issue is that Bonjour is trying to use the internal docker interface. You can fix this as so: Change Bonjour interface/IP bind order

If you let me know the name of the interface from http://192.168.1.4:8089/system/network, I can push out an update which ignores it by default.

I’m also working on a Bonjour fix to work correctly with multiple network interfaces.

#4 
[{"mtu":65536,"name":"lo","hardwareaddr":"","flags":["up","loopback"],"addrs":[{"addr":"127.0.0.1/8"},{"addr":"::1/128"}]},{"mtu":1500,"name":"eno1","hardwareaddr":"3c:a8:2a:4b:a4:08","flags":["up","broadcast","multicast"],"addrs":[]},{"mtu":1500,"name":"eno2","hardwareaddr":"3c:a8:2a:4b:a4:09","flags":["broadcast","multicast"],"addrs":[]},{"mtu":1500,"name":"br-29143d3039ee","hardwareaddr":"02:42:ba:11:4f:50","flags":["up","broadcast","multicast"],"addrs":[{"addr":"172.18.0.1/16"},{"addr":"fe80::42:baff:fe11:4f50/64"}]},{"mtu":1500,"name":"docker0","hardwareaddr":"02:42:15:91:00:9f","flags":["up","broadcast","multicast"],"addrs":[{"addr":"172.17.0.1/16"},{"addr":"fe80::42:15ff:fe91:9f/64"}]},{"mtu":1500,"name":"vethcdbad0a","hardwareaddr":"2a:e8:7a:d4:28:bf","flags":["up","broadcast","multicast"],"addrs":[{"addr":"fe80::28e8:7aff:fed4:28bf/64"}]},{"mtu":1500,"name":"br0","hardwareaddr":"3c:a8:2a:4b:a4:08","flags":["up","broadcast","multicast"],"addrs":[{"addr":"192.168.1.4/24"},{"addr":"fe80::3ea8:2aff:fe4b:a408/64"}]},{"mtu":1500,"name":"vif3.0","hardwareaddr":"fe:ff:ff:ff:ff:ff","flags":["up","broadcast","multicast"],"addrs":[{"addr":"fe80::fcff:ffff:feff:ffff/64"}]},{"mtu":1500,"name":"vethf99eeda","hardwareaddr":"b2:aa:83:45:11:43","flags":["up","broadcast","multicast"],"addrs":[{"addr":"fe80::b0aa:83ff:fe45:1143/64"}]},{"mtu":1500,"name":"veth13148b0","hardwareaddr":"4e:3c:55:41:e2:2f","flags":["up","broadcast","multicast"],"addrs":[{"addr":"fe80::4c3c:55ff:fe41:e22f/64"}]}]

Obviously a bit of a mess but I’ve got some ideas:

  • MAC OUI prefix of 02:42:ba - could be Docker always uses that?
  • Grab the OUI prefix of the docker0 device and ignore all devices that have that same OUI prefix

Not sure how practical that is.

#5

I could ignore br-*

Using curl to force br0 should fix your issue.

#6

I ended up running curl -XPUT http://192.168.1.4:8089/bonjour/interface/br0 and it returned true. However from within the Channels app I got:

DVR Access Failure
An SSL error has occurred and a secure connection to the server cannot be made.

After I tried to “Login to Remote DVR”.

Unless I’m suppose to see a DVR menu at the top of the screen? I’ve only got

  • On Now
  • Guide
  • Settings
#7

fwiw,

$ curl http://192.168.1.4:8089/bonjour

{"addresses":["172.18.0.1","192.168.1.4"],"enabled":true,"hostname":"dvr-mcelwain.local.","interfaces":["br0"]}
#8

You don’t need to “login to remote DVR”. That is only for remote access.

On the DVR web page uncheck and recheck the Bonjour checkbox and ensure the right ip is listed underneath.

#9

Any luck?

#10

Sorry for not responding yesterday. I didn’t get a chance to try it until just now. Yes. Toggling that checkbox immediately fixed it.

1 Like
#11

Looks like you're right.

https://stackoverflow.com/questions/42946453/how-does-the-docker-assign-mac-addresses-to-containers