OpenDCT on Docker not finding HDHR

[Fuzzy]

Originally Posted by panteragstk

I've got this docker loaded so I can try to get my HDHR to record in h.264 instead of mpeg 2 and I'm not sure where to start with the docker.

I set it as a host and the /config dir is in /appdata/openDCT

After getting the docker running I don't see any files in the appdata dir.

What am I missing? A lot I'm guessing

appdata/opendct/etc/conf/opendct.properties should be there to be edited.
appdata/opendct/log/opendct.log should be there to be monitored.

These are only true if you didn't alter the paths that are setup in the docker container.

[CSCO_TECH]

For some information, I experienced something similar yesterday.

I built a new Unraid box and installed Sage and OpenDCT containers and my HDHR cable card tuner was discovered properly with out of the box network settings. I know it is out of order, but after getting everything running to test moving from my WHSv1 install, I decided to change to a permanent static IP and rename my host from Tower. I also have multiple NICs, but am only connected via one until I pass the others through to VMs.

After the network and host changes, Sage would no longer see my cable card tuner through OpenDCT. It could still talk directly to my old OTA HDHR. When looking at the log file, I was also only sending to 0.0.0.0 for discovery, even though it showed my 10.0.0.x/24 interface IP. I did a packet capture on my PC and could see the multicast discovery for Ceton being sent on the LAN but no broadcast for HDHR discovery. I don't have a log from when it initially worked because I didn't need to look at it. Everything just worked.

After reading this post, I was able to stop the container, add the line to the conf file to specify a broadcast static address csv of 10.0.0.255, and then restart the container. At that point discovery packets were sent to the local broadcast and all tuners were discovered via OpenDCT. I had deleted the previously discovered tuners from Sage and also removed the encoders from my properties file while troubleshooting.

In the end, I'm not sure why a discovery would be sent to a quad 0 IP address in the first place, as I'm not aware of any IPv4 use of 0.0.0.0 that relates to a LAN broadcast. It may work to discover a tuner installed directly to a server running OpenDCT. Otherwise, it should be 255.255.255.255 or a subnet specific broadcast. The default of most network routers these days should be to stop the packet at the L3 interface if you sent an all 255 broadcast.

Log before modifying conf file:

INFO   | jvm 1    | 2017/02/07 22:34:45.714 | 22:34:45.680 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - Network interfaces which are up and have an IP4 address are:
INFO   | jvm 1    | 2017/02/07 22:34:45.714 | name:br0 (br0) 10.0.0.111
INFO   | jvm 1    | 2017/02/07 22:34:45.714 | 22:34:45.694 [DynamicAsyncInit-22] INFO  DynamicConsumerImpl - Dynamic consumer default set to use opendct.consumer.MediaServerConsumerImpl
INFO   | jvm 1    | 2017/02/07 22:34:45.714 | 22:34:45.694 [DynamicAsyncInit-22] INFO  DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.FFmpegTransSageTVConsumerImpl for []
INFO   | jvm 1    | 2017/02/07 22:34:45.714 | 22:34:45.695 [DynamicAsyncInit-22] INFO  DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.MediaServerConsumerImpl for []
INFO   | jvm 1    | 2017/02/07 22:34:45.714 | 22:34:45.695 [DynamicAsyncInit-22] INFO  DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.RawSageTVConsumerImpl for []
INFO   | jvm 1    | 2017/02/07 22:34:45.814 | 22:34:45.739 [WrapperSimpleAppMain] INFO  UpnpManager - Starting UPnP services...
INFO   | jvm 1    | 2017/02/07 22:34:45.814 | 22:34:45.758 [WrapperSimpleAppMain] INFO  DCTDefaultUpnpServiceConfiguration - Using the interface 'br0' with IP address 10.0.0.111 for UPnP discover
y.
INFO   | jvm 1    | 2017/02/07 22:34:45.814 | 22:34:45.790 [UPnPDiscovery-34] INFO  UpnpManager - UPnP discovery thread has started.
INFO   | jvm 1    | 2017/02/07 22:34:45.914 | 22:34:45.840 [HDHomeRunDiscoverySend-35] INFO  HDHomeRunDiscovery - HDHomeRun discovery sender thread started.
INFO   | jvm 1    | 2017/02/07 22:34:45.915 | 22:34:45.840 [HDHomeRunDiscoveryReceive-35] INFO  HDHomeRunDiscovery - HDHomeRun discovery receive thread for /0.0.0.0:65001 broadcast started.
INFO   | jvm 1    | 2017/02/07 22:34:45.915 | 22:34:45.842 [WrapperSimpleAppMain] INFO  NanoHTTPDManager - Starting webserver on port 9091...
INFO   | jvm 1    | 2017/02/07 22:34:45.915 | 22:34:45.843 [HDHomeRunDiscoverySend-35] INFO  HDHomeRunDiscovery - Broadcasting HDHomeRun discovery packet to /0.0.0.0:65001... (startup)
INFO   | jvm 1    | 2017/02/07 22:34:45.915 | 22:34:45.865 [WrapperSimpleAppMain] INFO  Main - Running in daemon mode...
INFO   | jvm 1    | 2017/02/07 22:34:46.115 | 22:34:46.043 [HDHomeRunDiscoverySend-35] INFO  HDHomeRunDiscovery - Broadcasting HDHomeRun discovery packet to /0.0.0.0:65001... (startup)
INFO   | jvm 1    | 2017/02/07 22:34:46.315 | 22:34:46.244 [HDHomeRunDiscoverySend-35] INFO  HDHomeRunDiscovery - Broadcasting HDHomeRun discovery packet to /0.0.0.0:65001... (startup)
INFO   | jvm 1    | 2017/02/07 22:34:46.516 | 22:34:46.445 [HDHomeRunDiscoverySend-35] INFO  HDHomeRunDiscovery - Broadcasting HDHomeRun discovery packet to /0.0.0.0:65001... (startup)
INFO   | jvm 1    | 2017/02/07 22:35:17.854 | 22:35:17.797 [UPnPDiscovery-34] WARN  DiscoveryRegistryListener - Before UPnP shutdown, the registry did not contain any devices.

Section of modified conf file (and still current after docker start):

hdhr.ignore_models=
hdhr.locking=true
hdhr.offline_detection_min_bytes=10528
hdhr.retry_count=2
hdhr.smart_broadcast=true
hdhr.static_addresses_csv=10.0.0.255
hdhr.wait_for_offline_detection_s=8
hdhr.wait_for_streaming=15000

Log after modifying conf file:

23:19:05.858 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - Network interfaces which are up and have an IP4 address are:
name:br0 (br0) 10.0.0.111
23:19:05.872 [DynamicAsyncInit-22] INFO  DynamicConsumerImpl - Dynamic consumer default set to use opendct.consumer.MediaServerConsumerImpl
23:19:05.872 [DynamicAsyncInit-22] INFO  DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.FFmpegTransSageTVConsumerImpl for []
23:19:05.873 [DynamicAsyncInit-22] INFO  DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.MediaServerConsumerImpl for []
23:19:05.873 [DynamicAsyncInit-22] INFO  DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.RawSageTVConsumerImpl for []
23:19:05.918 [WrapperSimpleAppMain] INFO  UpnpManager - Starting UPnP services...
23:19:05.937 [WrapperSimpleAppMain] INFO  DCTDefaultUpnpServiceConfiguration - Using the interface 'br0' with IP address 10.0.0.111 for UPnP discovery.
23:19:05.958 [WrapperSimpleAppMain] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
23:19:05.967 [UPnPDiscovery-34] INFO  UpnpManager - UPnP discovery thread has started.
23:19:06.019 [HDHomeRunDiscoverySend-35] INFO  HDHomeRunDiscovery - HDHomeRun discovery sender thread started.
23:19:06.020 [HDHomeRunDiscoveryReceive-35] INFO  HDHomeRunDiscovery - HDHomeRun discovery receive thread for /0.0.0.0:65001 broadcast started.
23:19:06.022 [WrapperSimpleAppMain] INFO  NanoHTTPDManager - Starting webserver on port 9091...
23:19:06.022 [HDHomeRunDiscoverySend-35] INFO  HDHomeRunDiscovery - Transmitting HDHomeRun discovery packets to /10.0.0.255:65001... (startup)
23:19:06.029 [HDHomeRunDiscoveryReceive-35] DEBUG HDHomeRunControl - key: '/tuner0/lockkey' value: 'null' lockKey: '0' sendLength: 26 address: 10.0.0.24
23:19:06.033 [HDHomeRunDiscoveryReceive-35] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26 address: 10.0.0.24
23:19:06.035 [HDHomeRunDiscoveryReceive-35] DEBUG HDHomeRunControl - key: '/tuner2/lockkey' value: 'null' lockKey: '0' sendLength: 26 address: 10.0.0.24
23:19:06.037 [HDHomeRunDiscoveryReceive-35] DEBUG HDHomeRunDiscovery - HDHomerun device returned an unknown tag with the length 31. This can be ignored.
23:19:06.038 [HDHomeRunDiscoveryReceive-35] DEBUG HDHomeRunControl - key: '/sys/hwmodel' value: 'null' lockKey: '0' sendLength: 23 address: 10.0.0.24
23:19:06.039 [HDHomeRunDiscoveryReceive-35] INFO  HDHomeRunDiscoverer - Discovered a new HDHomeRun device 'HDHomeRun DRI Tuner 1311B773' with 3 tuners.
23:19:06.043 [HDHomeRunDiscoveryReceive-35] DEBUG DeviceLoaderImpl - Advertising new capture device 'DCT-HDHomeRun Prime Tuner 1311B773-0'.

My ifconfig:

bond0: flags=5443<UP,BROADCAST,RUNNING,PROMISC,MASTER,MULTICAST>  mtu 1500
        ether d0:50:99:64:38:7d  txqueuelen 1000  (Ethernet)
        RX packets 84437  bytes 108294209 (103.2 MiB)
        RX errors 0  dropped 30  overruns 0  frame 0
        TX packets 37041  bytes 4170922 (3.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.111  netmask 255.255.255.0  broadcast 0.0.0.0
        ether d0:50:99:64:38:7d  txqueuelen 1000  (Ethernet)
        RX packets 57411  bytes 105354793 (100.4 MiB)
        RX errors 0  dropped 110  overruns 0  frame 0
        TX packets 36402  bytes 3976795 (3.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 0.0.0.0
        ether 02:42:ae:2b:c0:81  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether d0:50:99:64:38:7d  txqueuelen 1000  (Ethernet)
        RX packets 84437  bytes 108294209 (103.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 37041  bytes 4170922 (3.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xfb300000-fb320000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.255.255.255
        loop  txqueuelen 1  (Local Loopback)
        RX packets 675  bytes 41056 (40.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 675  bytes 41056 (40.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:c0:0e:7b  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

If anyone needs more detail, let me know and I'll see what I can do. My next step is to remove the bonding and bridging from my primary interface and connect my VMs through ETH1 and or ETH2. For what it is worth, the use case is that I want to pass my other NIC(s) directly to the VM(s) for 802.1x configurations on my switch.

LSPCI shows them all in different IOMMU groups. I did also reassign my interfaces, as ETH0 was originally not my onboard Intel NIC.

IOMMU 18 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V (rev 05)
IOMMU 29 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
IOMMU 30 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

Mark

[mechling-burgh]

I had the same problem with the docker, it was working but I could not find it any where. I uninstalled the docker and reinstalled. I think the first time I tryed to install it I may tried to create the docker when all you have to do is add the path then it appears in the drop down box as an option.

[EnterNoEscape]

Originally Posted by CSCO_TECH

In the end, I'm not sure why a discovery would be sent to a quad 0 IP address in the first place, as I'm not aware of any IPv4 use of 0.0.0.0 that relates to a LAN broadcast. It may work to discover a tuner installed directly to a server running OpenDCT. Otherwise, it should be 255.255.255.255 or a subnet specific broadcast. The default of most network routers these days should be to stop the packet at the L3 interface if you sent an all 255 broadcast.

As you can see in ifconfig, the broadcast address for whatever reason is 0.0.0.0 (means any address) and that's what OpenDCT is pulling in. I was going to add something to automatically generate a correct broadcast based on your subnet mask, but I have not got around to it just yet. In the case of Docker 255.255.255.255 might be ok for most people, but it's not ok in a multi-NIC environment because it will only be broadcasted from the gateway NIC and might not be the one you want. What you did to address this for now is my best advice.

[panteragstk]

Originally Posted by Fuzzy

appdata/opendct/etc/conf/opendct.properties should be there to be edited.
appdata/opendct/log/opendct.log should be there to be monitored.

These are only true if you didn't alter the paths that are setup in the docker container.

is OpenDCT expecting it's internal folder to be called /config like other dockers?

That may be where I'm going wrong.

Container volume: /config Host path: /cache/appdata/openDCT

[Fuzzy]

Your best bet to simply not touch the paths. And just use what are default in the template.

/etc/opendct is mapped to /mnt/user/appdata/opendct/etc
/var/log/opendct is mapped to /mnt/user/appdata/opendct/log
/opt/opendct Is mapped to /mnt/user/appdata/opendct/opt

[BobbyDing]

So I'm still having issues trying to install this. I removed the opendct container (and image) from last week. Removed it from Community Applications, and deleted the opendct folder from mnt/user/appdata. I re installed using the standard docker install (not CA), selecting the opendct-docker template, which downloaded, installed and started. I stopped the container, added the line "hdhr.static_addresses_csv=192.168.1.255" and restarted. Once again this line disappeared from the properties file. The profile_example.properties file in the transcode folder is also still being re installed as earlier.
.
Might I be pulling the wrong image? Or might it be cached somewhere locally that causes it to re install the same image as earlier? Log files attached.

Thanks!

Bobby

Note:
192.168.1.180 is unraid on my network
192.168.122.1 is a win7 VM that was also running at the time.

[Fuzzy]

Still no idea what is going on with the networking on your system. With the container in HOST, you should have a docker0: interface (this is the docker control channel) with a 172.17.0.1 address, and a br0: interface (this is the host's interface) with the exact same address as your unRAID server itself. The fact that your docker container is seeing itself as having the same address as a windows VM on your network makes me think that the responses to the broadcast are being sent to the windows vm, which is why the docker container isn't ever receiving them.

What is your unRAID server's IP address? What version of unRAID are your running?

[BobbyDing]

unraid 6.2.1. The servers address on the network is 192.168.1.180.

Last night I stopped all the containers and the Win 7 VM and tried it again but didn't see any change. I left everything overnight. This morning I started the opendct container again and it is working! Odct is seeing all my HDHR tuners and Sage is using them so far. Leaving it sit overnight was the key for me. I have no idea why this is. I'm posting today's logs. Perhaps there's a clue in there somewhere.

I appreciate all the help with this...

Bobby

[panteragstk]

Originally Posted by Fuzzy

Your best bet to simply not touch the paths. And just use what are default in the template.

/etc/opendct is mapped to /mnt/user/appdata/opendct/etc
/var/log/opendct is mapped to /mnt/user/appdata/opendct/log
/opt/opendct Is mapped to /mnt/user/appdata/opendct/opt

That would be the issue then, nothing showed up in the template. I'll mess with it again with your paths now that I've updated from unRAID v 6.1.9 to v6.3.1

EDIT: That did it. Thanks. Not sure why the docker didn't already have paths, but manually adding them worked.

[BobbyDing]

Originally Posted by Fuzzy

Still no idea what is going on with the networking on your system. With the container in HOST, you should have a docker0: interface (this is the docker control channel) with a 172.17.0.1 address, and a br0: interface (this is the host's interface) with the exact same address as your unRAID server itself. The fact that your docker container is seeing itself as having the same address as a windows VM on your network makes me think that the responses to the broadcast are being sent to the windows vm, which is why the docker container isn't ever receiving them.

Fuzzy, I believe you are right. I must have a networking issue. Odct worked for a bit and is choking again. I do remember seeing 172.17.0.1 address in the odct logs a while back, but it disappeared and I cannot explain why. I think I'll remove the VM and docker and start from scratch.

Thanks!

Bobby

[BobbyDing]

So I'm back again and still needing help. I removed (and deleted) all VM & Docker images from unraid, upgraded unraid to 6.3.1. Rebooted. started the array and installed a new docker image file. Installed odct docker first. Same problem as before... Only seeing eth0, which is 192.168.1.180 and no logged responses from the tuners. I don't think it saw docker0 either. Then added the line hdhr.static_addresses_csv=, which brought in all my tuners according to the log file(s). But after odct was stopped, the odct.properties file only shows a dct single tuner from the hdhr prime (I would think it should have listed all 3) and none of the other ota tuners. I then installed the sage docker and it saw all the available tuners. I installed a single dct tuner and a single ota tuner and I am able to use them, then I stopped sage, waited a bit and stopped odct. Still the odct.properties file was not updated beyond the single tuner and though the linups are being created, they are not populating. This may be an unraid network issue or maybe something funky about my hardware, but I don't think the unraid forums would be any help regarding the sage specific dockers. Other dockers like plex, emby, sickrage all worked fine when they were installed and I've always chosen the recommended settings with unraid. Any ideas on things to try would be appreciated.

Logs attached. Including my docker log.

Thanks,

Bobby

Question(s): What might stop the odct.properties file from updating when odct exits? And should simply stopping the container make this happen? Or does this happen some other way? Could it be a security (access) thing? Or that unraid is set to HOST in the networking settings? Thanks.
.

[BobbyDing]

I'm thinking now it's my unraid network settings. It is set for HOST. Should it be set to BRIDGED?

Update: Setting unraid to bridged gave odct br0 instead of eth0, but all else is the same. Odct is seeing all my tuners with the hdhr.static_addresses_csv= line, but not updating the .properties file with what it has found. Is there a way to force odct to update the .properties file say after running for 1 minute instead of waiting for it to exit?

Thanks!

and sorry for all the posting.

[BobbyDing]

Open-dct is now working network wise due to the description CSCO_TECH gave above. I set the unraid box back to DHCP for the IP as well as the DNS, removed, then reinstalled crazifuzzy-opendct (to insure a new .properties file) and opendct came up finding my hdhr devices immediately without adding an IP to hdhr.static_addresses_csv=. I'm not sure why the static config in unraid did not work, but the sage docker sees and uses the tuners just fine (though the all tuner descriptions in sage now say tower.home:9000 instead of their IP.

This leaves one issue. opendct.properties is not being updated fully. It gets as far as adding some of my prime tuners, then stops without finishing those tuners and not adding any OTA tuners. opendct.properties never gets past 5K in size. Also, I notice all the linups get created, but not populated.

Any ideas what might be causing this? Logs attached.

Thanks so much,

Bobby

[willieb]

I got OpenDCT working on my new unRAID server last night, but only after a lot of failures discovering my HDHR. I finally read this thread and added:

hdhr.static_addresses_csv=255.255.255.255

To my properties file and everything worked without a hitch!

Thanks again for everyone's help!

[stuckless]

Originally Posted by EnterNoEscape

In the case of Docker 255.255.255.255 might be ok for most people, but it's not ok in a multi-NIC environment because it will only be broadcasted from the gateway NIC and might not be the one you want.

Someone was kind enough to send me an HDHR. I finally got around to testing it out. As for the HDHR, the only thing I have done is plug it in, and connect an antannae, and connected an ethernet cable to it. I installed the opendct docker container, and from the logs it doesn't appear to find it (similar issues as to what others are seeing here).

I'm not 100% sure what I should do next. I'm going to see if I can find it's IP address and try the suggestion to add it explicitly and see what happens.

Launching OpenDCT
Running OpenDCT Digital Cable Tuner for SageTV...
STATUS | wrapper | 2017/03/25 06:53:11.788 | --> Wrapper Started as Console
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[0] : /usr/bin/java
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[1] : -Dopendct_log_root=/var/log/opendct
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[2] : -Dconfig_dir=/etc/opendct/conf
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[3] : -Ddaemon_mode=true
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[4] : -XX:ErrorFile=/var/log/opendct/hs_err_pid%p.log
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[5] : -verbose:gc
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[6] : -XX:+UseG1GC
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[7] : -Xms128m
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[8] : -Xmx768m
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[9] : -Djava.library.path=/opt/opendct/jsw/lib:/opt/opendct/lib
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[10] : -classpath
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[11] : /opt/opendct/jsw/lib/wrapper.jar:/opt/opendct/lib/opendct-0.5.25.jar:/opt/opendct/lib/cling-core-2.1.1.jar:/opt/opendct/lib/log4j-api-2.5.jar:/opt/opendct/lib/log4j-core-2.5.jar:/opt/opendct/lib/jna-4.2.1.jar:/opt/opendct/lib/jna-platform-4.2.1.jar:/opt/opendct/lib/nanohttpd-2.3.0.jar:/opt/opendct/lib/nanohttpd-nanolets-2.3.0.jar:/opt/opendct/lib/gson-2.8.0.jar:/opt/opendct/lib/javacpp-1.1.jar:/opt/opendct/lib/ffmpeg-2.8.1-1.1.jar:/opt/opendct/lib/ffmpeg-2.8.1-1.1-linux-x86_64.jar:/opt/opendct/lib/seamless-util-1.1.1.jar:/opt/opendct/lib/seamless-http-1.1.1.jar:/opt/opendct/lib/seamless-xml-1.1.1.jar
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[12] : -Dwrapper.key=9QFmBvNZUL2jJzWA
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[13] : -Dwrapper.port=32001
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[14] : -Dwrapper.jvm.port.min=31000
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[15] : -Dwrapper.jvm.port.max=31999
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[16] : -Dwrapper.pid=157
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[17] : -Dwrapper.version=3.2.3

INFO | wrapper | 2017/03/25 06:53:11.990 | Command[18] : -Dwrapper.native_library=wrapper
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[19] : -Dwrapper.cpu.timeout=10
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[20] : -Dwrapper.jvmid=1
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[21] : org.tanukisoftware.wrapper.WrapperSimpleApp
INFO | wrapper | 2017/03/25 06:53:11.990 | Command[22] : opendct.Main
STATUS | wrapper | 2017/03/25 06:53:11.990 | Launching a JVM...
INFO | jvm 1 | 2017/03/25 06:53:12.191 | Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org

INFO | jvm 1 | 2017/03/25 06:53:12.191 | Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved.
INFO | jvm 1 | 2017/03/25 06:53:12.191 |
INFO | jvm 1 | 2017/03/25 06:53:12.692 | 06:53:12.614 [WrapperSimpleAppMain] INFO Main - Starting OpenDCT 0.5.25...
INFO | jvm 1 | 2017/03/25 06:53:12.692 | 06:53:12.638 [WrapperSimpleAppMain] INFO Config - Current directory is '/opt/opendct'
INFO | jvm 1 | 2017/03/25 06:53:12.692 | 06:53:12.683 [WrapperSimpleAppMain] INFO Main - OpenDCT logging to the directory '/var/log/opendct'.
INFO | jvm 1 | 2017/03/25 06:53:12.792 | 06:53:12.698 [WrapperSimpleAppMain] INFO UpnpManager - Logging Cling UPnP to '/var/log/opendct/opendct_cling.log'.
INFO | jvm 1 | 2017/03/25 06:53:12.792 | [GC pause (G1 Evacuation Pause) (young) 24M->4639K(128M), 0.0158644 secs]
INFO | jvm 1 | 2017/03/25 06:53:12.792 | 06:53:12.716 [FFmpegAsyncInit-23] INFO Main - FFmpeg loading...
INFO | jvm 1 | 2017/03/25 06:53:12.792 | 06:53:12.717 [WrapperSimpleAppMain] WARN LinuxPowerMessagePump - System power state messages are currently not implemented for Linux.
INFO | jvm 1 | 2017/03/25 06:53:13.193 | 06:53:13.125 [FFmpegAsyncInit-23] INFO Main - FFmpeg loaded in 426ms.
INFO | jvm 1 | 2017/03/25 06:53:17.799 | 06:53:17.721 [WrapperSimpleAppMain] INFO NetworkPowerEventManger - Network interfaces which are up and have an IP4 address are:
INFO | jvm 1 | 2017/03/25 06:53:17.799 | name:docker0 (docker0) 172.17.0.1
INFO | jvm 1 | 2017/03/25 06:53:17.799 | name:br0 (br0) 192.168.1.10
INFO | jvm 1 | 2017/03/25 06:53:17.799 | 06:53:17.738 [DynamicAsyncInit-23] INFO DynamicConsumerImpl - Dynamic consumer default set to use opendct.consumer.MediaServerConsumerImpl
INFO | jvm 1 | 2017/03/25 06:53:17.799 | 06:53:17.739 [DynamicAsyncInit-23] INFO DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.FFmpegTransSageTVConsumerImpl for []
INFO | jvm 1 | 2017/03/25 06:53:17.799 | 06:53:17.740 [DynamicAsyncInit-23] INFO DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.MediaServerConsumerImpl for []
INFO | jvm 1 | 2017/03/25 06:53:17.799 | 06:53:17.740 [DynamicAsyncInit-23] INFO DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.RawSageTVConsumerImpl for []
INFO | jvm 1 | 2017/03/25 06:53:17.799 | 06:53:17.748 [WrapperSimpleAppMain] WARN HDHomeRunDiscovery - Broadcast IP address was any local address. Using 255.255.255.255 instead.
INFO | jvm 1 | 2017/03/25 06:53:17.799 | 06:53:17.748 [WrapperSimpleAppMain] WARN HDHomeRunDiscovery - Broadcast IP address was any local address. Using 255.255.255.255 instead.
INFO | jvm 1 | 2017/03/25 06:53:17.799 | 06:53:17.765 [WrapperSimpleAppMain] INFO UpnpManager - Starting UPnP services...
INFO | jvm 1 | 2017/03/25 06:53:17.799 | 06:53:17.779 [WrapperSimpleAppMain] INFO DCTDefaultUpnpServiceConfiguration - Using the interface 'docker0' with IP address 172.17.0.1 for UPnP discovery.
INFO | jvm 1 | 2017/03/25 06:53:17.799 | 06:53:17.779 [WrapperSimpleAppMain] INFO DCTDefaultUpnpServiceConfiguration - Using the interface 'br0' with IP address 192.168.1.10 for UPnP discovery.
INFO | jvm 1 | 2017/03/25 06:53:17.899 | 06:53:17.811 [UPnPDiscovery-40] INFO UpnpManager - UPnP discovery thread has started.
INFO | jvm 1 | 2017/03/25 06:53:17.899 | 06:53:17.869 [WrapperSimpleAppMain] ERROR HDHomeRunDiscovery - Unable to use port 64998, using any port available.

INFO | jvm 1 | 2017/03/25 06:53:17.899 | 06:53:17.870 [HDHomeRunDiscoveryReceive-41] INFO HDHomeRunDiscovery - HDHomeRun discovery receive thread for /255.255.255.255:65001 broadcast started.
INFO | jvm 1 | 2017/03/25 06:53:17.899 | 06:53:17.870 [HDHomeRunDiscoverySend-41] INFO HDHomeRunDiscovery - HDHomeRun discovery sender thread started.
INFO | jvm 1 | 2017/03/25 06:53:17.899 | 06:53:17.870 [HDHomeRunDiscoveryReceive-41] INFO HDHomeRunDiscovery - HDHomeRun discovery receive thread for /255.255.255.255:65001 broadcast started.
INFO | jvm 1 | 2017/03/25 06:53:17.899 | 06:53:17.872 [WrapperSimpleAppMain] INFO NanoHTTPDManager - Starting webserver on port 9091...
INFO | jvm 1 | 2017/03/25 06:53:17.899 | 06:53:17.872 [HDHomeRunDiscoverySend-41] INFO HDHomeRunDiscovery - Broadcasting HDHomeRun discovery packet to /255.255.255.255:65001... (startup)
INFO | jvm 1 | 2017/03/25 06:53:17.899 | 06:53:17.873 [HDHomeRunDiscoverySend-41] INFO HDHomeRunDiscovery - Broadcasting HDHomeRun discovery packet to /255.255.255.255:65001... (startup)
INFO | jvm 1 | 2017/03/25 06:53:17.899 | 06:53:17.896 [WrapperSimpleAppMain] INFO Main - Running in daemon mode...
INFO | jvm 1 | 2017/03/25 06:53:18.100 | 06:53:18.073 [HDHomeRunDiscoverySend-41] INFO HDHomeRunDiscovery - Broadcasting HDHomeRun discovery packet to /255.255.255.255:65001... (startup)
INFO | jvm 1 | 2017/03/25 06:53:18.100 | 06:53:18.074 [HDHomeRunDiscoverySend-41] INFO HDHomeRunDiscovery - Broadcasting HDHomeRun discovery packet to /255.255.255.255:65001... (startup)
INFO | jvm 1 | 2017/03/25 06:53:18.301 | 06:53:18.275 [HDHomeRunDiscoverySend-41] INFO HDHomeRunDiscovery - Broadcasting HDHomeRun discovery packet to /255.255.255.255:65001... (startup)

[stuckless]

Originally Posted by stuckless

Someone was kind enough to send me an HDHR. I finally got around to testing it out. As for the HDHR, the only thing I have done is plug it in, and connect an antannae, and connected an ethernet cable to it. I installed the opendct docker container, and from the logs it doesn't appear to find it (similar issues as to what others are seeing here).

I'm not 100% sure what I should do next. I'm going to see if I can find it's IP address and try the suggestion to add it explicitly and see what happens.

Ok... so this happened You know how I said, "and connected ethernet"... apparently that didn't happen OpenDCT is discovering it now. I still don't see it in SageTV... so I'll go looking for some information on that.

[EnterNoEscape]

Originally Posted by stuckless

Ok... so this happened You know how I said, "and connected ethernet"... apparently that didn't happen OpenDCT is discovering it now. I still don't see it in SageTV... so I'll go looking for some information on that.

The reason 255.255.255.255 is such a bad idea is because it will just use whatever is considered the primary adapter. That means its reliability will be a little random when there's more than one adapter. I'm not sure that generating what should be the broadcast address will fair better, but I will eventually get around to that. It's just a lot of bit-math that I don't personally enjoy doing. This is really only a Docker problem because of the strange way it does networking.

You likely just need to restart SageTV and/or make sure network_encoder_discovery=false is true. This is now the default, but I'm guessing when you set things up it was still disabled by default.

[stuckless]

Originally Posted by EnterNoEscape

The reason 255.255.255.255 is such a bad idea is because it will just use whatever is considered the primary adapter. That means its reliability will be a little random when there's more than one adapter. I'm not sure that generating what should be the broadcast address will fair better, but I will eventually get around to that. It's just a lot of bit-math that I don't personally enjoy doing. This is really only a Docker problem because of the strange way it does networking.

You likely just need to restart SageTV and/or make sure network_encoder_discovery=false is true. This is now the default, but I'm guessing when you set things up it was still disabled by default.

Yeah, after restarting both dockers... sagetv was able to find it. It's all setup... It only found 3 channels But that's not OpenDCT's fault... I just live in an area that has very few channels

[willieb]

Originally Posted by EnterNoEscape

The reason 255.255.255.255 is such a bad idea is because it will just use whatever is considered the primary adapter. That means its reliability will be a little random when there's more than one adapter. I'm not sure that generating what should be the broadcast address will fair better, but I will eventually get around to that. It's just a lot of bit-math that I don't personally enjoy doing. This is really only a Docker problem because of the strange way it does networking.

You likely just need to restart SageTV and/or make sure network_encoder_discovery=false is true. This is now the default, but I'm guessing when you set things up it was still disabled by default.

OK. so it sounds like I should remove the 255.255.255.255 that I added and change network_encoder_discovery then? I'm not 100% sure if I am following what you mean by reliability being a little random. I have recently seen a few cases where Sage was using a much lower merit tuner (the lowest) when there were 5 HDHR tuners with higher merit available. Could that be related? I didn't think so -- I know the way Sage picks encoders can involve a bit of black magic sometimes, so I just thought there was some reason it decided to do that.