Unfortunately, I am on Windows 10. Wish I was Mac OS so that I could help.
Same problem on Synology 415+ but just started yesterday. All my recordings are OTA and strong signal. Was fine until I updated hdhomerun extend to 20170930 and played with the late and early start times by 1 minute (+1 and -1 sort of thing). Currently on Plex 1.9.2.4285 will try 1.9.4.4325.
@bpcomp said:
I don’t know if my logs will help since they aren’t fresh but I had 4 recordings yesterday that say complete, are in the grab folder but are stuck there.
Grab folder - can I get recordings out of that? where is it?
@edward.kosloski said:
@bpcomp said:
I don’t know if my logs will help since they aren’t fresh but I had 4 recordings yesterday that say complete, are in the grab folder but are stuck there.Grab folder - can I get recordings out of that? where is it?
Sometimes you can. The folder is named .grab and located in the folder where you tell Plex to store the DVR recordings. During a recording event and after some frozen events you’ll see folders inside with long serial number type names.
I’m experiencing this issue as well, have there been any more developments on solving the 100% complete bug?
@jaloomis111 said:
I’m experiencing this issue as well, have there been any more developments on solving the 100% complete bug?
We’re working on it. We’re looking for users to run some additional tests, including to test a patch. See my earlier comment.
Thanks Kino, I’m running a windows 10 server, so I don’t think I’m eligible for your patch, right?
Thanks Kino, I’m running a windows 10 server with homerun connect, so I don’t think I’m eligible for your patch, right?
@jaloomis111 said:
Thanks Kino, I’m running a windows 10 server with homerun connect, so I don’t think I’m eligible for your patch, right?
Sorry, the testing patch is only being built for macOS, but the fix will roll out to all 
Same issue - got worse with latest update:
Version 1.9.2.4285
Nvidia Shield server
Logs attached.
My setup: PMS on NVIDIA Shield Pro, 1.9.2. but updated this morning to 1.9.4. HDHR Extend on the latest firmware (30 SEP I think). Shield and HDHR hardwired via a 4 port network switch (Netgear) to my router.
At first I thought I had a poor signal problem, and worked hard to get my signal better, and I did. But I still had the 100% recording bug, mostly (but not always) with 2 recordings happening simultaneously.
I started looking at the HDHR status log, and noticed the HDHR was getting “watchdog resets” regularly. I then started looking into what causes those resets, and read on an Emby forum who was experiencing Watchdog resets.
He eventually traced it to the network switch, which supposedly doesn’t play well with the HDHR and is the cause of the watchdog resets. To test, I took my switch out of the equation and replaced with a spare router I had and configured it to act like a switch. Since I did this two days ago, I’ve been 100% successful at recordings. Yesterday, morning recordings were on 1.9.2., and by the evening, recordings were on 1.9.4. I’ve had zero “watchdog resets.”
I don’t know how these dummy “no configuration” switches work, but maybe there’s something with it that upsets either PMS or HDHR, or both. I wanted to try using Static IPs, but HDHR doesn’t seem to support it (I had already reserved IPs in the router lonf ago).
Not saying this is the answer, I’m sure plenty on here aren’t using a switch, but I throw it out there as something that so far is working for me.
@yooshaw, thanks for those insights. I’ve passed them along to engineering.
@yooshaw
That switch thing seems pretty weird. I wonder what it could be doing to cause the watchdog reset.
I guess it’s safe to say that if you see have successful recordings and the frozen recordings stick to specific channels then it’s not likely a switch problem.
Do the watchdog reset messages show up here on the tuner? http://192.168.x.x/log.html
Also, were you saying the watchdog reset is an issue with the latest firmware 9/30/2017 HDHR firmware or were you just mentioning that in the description of your setup?
@kamererhouse said:
That switch thing seems pretty weird. I wonder what it could be doing to cause the watchdog reset.I guess it’s safe to say that if you see have successful recordings and the frozen recordings stick to specific channels then it’s not likely a switch problem.
My experience in testing has confined the issue with regard to OTA to specific channels where I have lower reception, or experience more signal noise. We’ve got our top transcoder engineer looking into this, but sample media has been harder to get. I went through a bunch of failed recordings only to see it stop. Now I have the good problem of not being able to get a failed recording for repro. We’ve got samples from users, and several of us are still working to better reproduce the issue while the transcoder engineer investigates further.
@kamererhouse said:
@yooshaw
That switch thing seems pretty weird. I wonder what it could be doing to cause the watchdog reset.I guess it’s safe to say that if you see have successful recordings and the frozen recordings stick to specific channels then it’s not likely a switch problem.
Do the watchdog reset messages show up here on the tuner? http://192.168.x.x/log.html
Also, were you saying the watchdog reset is an issue with the latest firmware 9/30/2017 HDHR firmware or were you just mentioning that in the description of your setup?
I don’t know if the issue is HDHR firmware related or not, I just mentioned it for my setup.
Here’s the current log, the first entry is the watchdog reset. The network link down/up messages was when I was putting in my re-configured router: The watchdog reset erases the current log and starts over, just like unplugging the HDHR.
19700101-00:00:17 System: reset reason = application watchdog
19700101-00:00:17 System: E5592573 0000000E 004E2A48 0042D05C 00432440 0040D8A4 004DD9CC 004DD9A0
19700101-00:00:17 System: 005099CC FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
19700101-00:00:18 System: network link 100f
19700101-00:00:19 System: ip address obtained: 192.168.29.111 / 255.255.255.0
20171010-22:33:55 System: time changed from Thu Jan 1 00:00:34 1970 to Tue Oct 10 22:33:55 2017
20171010-23:39:03 System: network link down
20171010-23:39:03 System: ip address expired
20171010-23:40:06 System: network link 100f
20171010-23:40:07 System: network link down
20171010-23:40:09 System: network link 100f
20171010-23:40:48 System: myhdhomerun_sync: webclient error (dns failed)
20171010-23:40:59 System: network link down
20171010-23:41:00 System: network link 100f
20171010-23:41:15 System: network link down
20171010-23:41:17 System: network link 100f
20171010-23:41:20 System: network link down
20171010-23:41:22 System: network link 100f
20171010-23:41:23 System: ip address obtained: 192.168.29.111 / 255.255.255.0
20171011-01:00:02 Tuner: tuner0 tuning 8.1 WFLA-HD (8vsb:177MHz-3)
20171011-01:00:02 Tuner: tuner0 streaming http to 192.168.29.163:42254
20171011-02:01:03 Tuner: tuner0 http stream ended (remote closed)
20171011-10:30:03 Tuner: tuner0 tuning 3.1 WEDU-HD (8vsb:213MHz-3)
20171011-10:30:03 Tuner: tuner0 streaming http to 192.168.29.163:37357
20171011-11:00:03 Tuner: tuner0 http stream ended (remote closed)
20171011-15:00:09 Tuner: tuner0 tuning 16.2 KIDS (8vsb:593MHz-4)
20171011-15:00:10 Tuner: tuner0 streaming http to 192.168.29.163:46513
20171011-15:30:03 Tuner: tuner0 http stream ended (remote closed)
20171011-17:30:09 Tuner: tuner0 tuning 3.4 WEDU+ (8vsb:213MHz-6)
20171011-17:30:09 Tuner: tuner1 tuning 16.2 KIDS (8vsb:593MHz-4)
20171011-17:30:09 Tuner: tuner0 streaming http to 192.168.29.163:53603
20171011-17:30:09 Tuner: tuner1 streaming http to 192.168.29.163:53604
20171011-18:00:02 Tuner: tuner0 http stream ended (remote closed)
20171011-18:00:05 Tuner: tuner1 http stream ended (remote closed)
20171011-22:30:04 Tuner: tuner0 tuning 10.1 WTSP-HD (8vsb:195MHz-1)
20171011-22:30:04 Tuner: tuner1 tuning 8.1 WFLA-HD (8vsb:177MHz-3)
20171011-22:30:04 Tuner: tuner0 streaming http to 192.168.29.163:39861
20171011-22:30:04 Tuner: tuner1 streaming http to 192.168.29.163:39862
20171011-23:00:06 Tuner: tuner0 http stream ended (remote closed)
20171011-23:00:07 Tuner: tuner1 http stream ended (remote closed)
20171012-00:00:03 Tuner: tuner0 tuning 3.1 WEDU-HD (8vsb:213MHz-3)
20171012-00:00:04 Tuner: tuner1 tuning 10.1 WTSP-HD (8vsb:195MHz-1)
20171012-00:00:04 Tuner: tuner0 streaming http to 192.168.29.163:34099
20171012-00:00:04 Tuner: tuner1 streaming http to 192.168.29.163:34098
20171012-02:00:00 Tuner: tuner1 http stream ended (remote closed)
20171012-02:00:00 Tuner: tuner0 http stream ended (remote closed)
20171012-02:00:04 Tuner: tuner0 tuning 10.1 WTSP-HD (8vsb:195MHz-1)
20171012-02:00:04 Tuner: tuner0 streaming http to 192.168.29.163:39636
20171012-03:00:06 Tuner: tuner0 http stream ended (remote closed)
20171012-10:30:02 Tuner: tuner0 tuning 3.1 WEDU-HD (8vsb:213MHz-3)
20171012-10:30:02 Tuner: tuner0 streaming http to 192.168.29.163:50129
20171012-11:00:02 Tuner: tuner0 http stream ended (remote closed)
20171012-15:00:07 Tuner: tuner0 tuning 16.2 KIDS (8vsb:593MHz-4)
20171012-15:00:08 Tuner: tuner0 streaming http to 192.168.29.163:59082
20171012-15:30:02 Tuner: tuner0 http stream ended (remote closed)
20171012-17:30:08 Tuner: tuner0 tuning 3.4 WEDU+ (8vsb:213MHz-6)
20171012-17:30:08 Tuner: tuner1 tuning 16.2 KIDS (8vsb:593MHz-4)
20171012-17:30:08 Tuner: tuner0 streaming http to 192.168.29.163:38815
20171012-17:30:08 Tuner: tuner1 streaming http to 192.168.29.163:38814
20171012-18:00:02 Tuner: tuner1 http stream ended (remote closed)
20171012-18:00:02 Tuner: tuner0 http stream ended (remote closed)
We’re getting in touch with SiliconDust to see if networking is the issue or part of the issue.
I’m having the same stuck-at-100%-recording bug on v1.9.4.4325 on Linux (unRaid) and a Hauppauge HVR-1250 card. I know it’s not an officially-supported card, but Live TV works just fine and my DVR issue is identical to the others in this topic. Just wanted to make sure the Plex folks knew this wasn’t ONLY a HomeRun problem. Note: restarting the (official) Plex docker will clear out the first failed recording and write it to the output folder but all subsequent ones that were recorded after the first one are lost.
@tomahawk1277 said:
I’m having the same stuck-at-100%-recording bug on v1.9.4.4325 on Linux (unRaid) and a Hauppauge HVR-1250 card. I know it’s not an officially-supported card, but Live TV works just fine and my DVR issue is identical to the others in this topic. Just wanted to make sure the Plex folks knew this wasn’t ONLY a HomeRun problem. Note: restarting the (official) Plex docker will clear out the first failed recording and write it to the output folder but all subsequent ones that were recorded after the first one are lost.
Thanks for that. If you’re interested in providing more testing insights on your tuner, take a look at our community supported tuners program.
Well, scratch the network switch theory. Just had it happen again - stuck on 100% with two simultaneous recordings. HDHR log shows the watchdog reset. After resetting PMS, the two shows have disappeared completely from the Recording schedule, and both recorded about 3 min of the 30 min show.
HDHR log:
9700101-00:00:17 System: reset reason = application watchdog
19700101-00:00:17 System: E5592573 0000000E 004E2A48 0042D05C 00432440 0040D8A4 004DD9CC 004DD9A0
19700101-00:00:17 System: 005099CC FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
19700101-00:00:18 System: network link 100f
19700101-00:00:19 System: ip address obtained: 192.168.29.111 / 255.255.255.0
20171012-22:33:57 System: time changed from Thu Jan 1 00:00:34 1970 to Thu Oct 12 22:33:57 2017
Somehow I knew that after I posted on here, it would fail. Sigh. Anyone else getting watchdog resets on HDHR?
I looked in the PMS log at the time the recording stopped. This looks to be where thing went awry. Not sure what it all means:
Oct 12, 2017 18:33:00.933 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:01.286 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:01.942 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:02.295 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:02.950 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:03.303 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:03.959 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:04.310 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:04.967 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:05.319 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:05.976 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:06.327 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:06.985 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:07.335 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:07.993 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:08.344 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:09.002 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:09.352 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:10.010 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:10.360 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:11.019 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:11.369 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:12.028 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:12.377 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:13.036 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:13.385 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:14.045 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:14.393 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:15.054 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:15.401 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:16.062 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:16.409 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:17.070 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:17.418 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:18.078 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:18.426 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:18.717 [22184] DEBUG - Activity: updated activity fb03b5ea-0153-44e8-9fdc-21ef3c6c51eb - completed 11% - Recording
Oct 12, 2017 18:33:18.718 [22184] DEBUG - Activity: updated activity 589f0b51-bf0f-4470-ad57-5e11e01e978f - completed 11% - Recording
Oct 12, 2017 18:33:19.087 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:19.435 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:20.095 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:20.442 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:21.104 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:21.450 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:22.112 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:22.458 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:23.120 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:23.467 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:24.129 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:24.475 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:25.137 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:25.484 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:26.146 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:26.491 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:27.154 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:27.500 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:27.707 [3744] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 29.679165 seconds: 192.168.29.111
Oct 12, 2017 18:33:27.712 [3744] DEBUG - DVR:Device: Discovering and refreshing devices.
Oct 12, 2017 18:33:27.714 [3744] DEBUG - DVR:Grabber: HDHomerun discovered 0 compatible devices.
Oct 12, 2017 18:33:27.714 [3744] DEBUG - DVR:Device: Testing grabber HDHomerun device device://tv.plex.grabbers.hdhomerun/10567791 at http://192.168.29.111:80
Oct 12, 2017 18:33:27.718 [3744] DEBUG - HTTP requesting GET http://192.168.29.111:80/discover.json
Oct 12, 2017 18:33:28.161 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:28.508 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:29.170 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:29.517 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:30.178 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:30.525 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:31.187 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:31.534 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:32.196 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:32.542 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:32.739 [3744] ERROR - Error issuing curl_easy_perform(handle): 28
Oct 12, 2017 18:33:32.739 [3744] DEBUG - HTTP simulating 408 after curl timeout
Oct 12, 2017 18:33:32.794 [3744] ERROR - DVR:Device: Error refreshing existing device device://tv.plex.grabbers.hdhomerun/10567791, marking as dead.
Oct 12, 2017 18:33:32.795 [3744] DEBUG - DVR:Grabber: Mystery discovered 0 compatible devices.
Oct 12, 2017 18:33:32.796 [3744] DEBUG - HTTP requesting POST http://127.0.0.1:32600/devices/discover
Oct 12, 2017 18:33:33.204 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:33.550 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:34.212 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:34.557 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:35.220 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:35.322 [3744] DEBUG - HTTP 200 response from POST http://127.0.0.1:32600/devices/discover
Oct 12, 2017 18:33:35.565 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:36.228 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:36.574 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:36.754 [22189] DEBUG - Activity: updated activity fb03b5ea-0153-44e8-9fdc-21ef3c6c51eb - completed 12% - Recording
Oct 12, 2017 18:33:36.754 [22189] DEBUG - Activity: updated activity 589f0b51-bf0f-4470-ad57-5e11e01e978f - completed 12% - Recording
Oct 12, 2017 18:33:37.237 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:37.581 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:38.246 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:38.589 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:39.254 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:39.597 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:40.263 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:40.606 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:41.271 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:41.614 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:42.279 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:42.622 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:43.287 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:43.630 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:44.296 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:44.637 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:45.304 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:45.646 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:45.946 [3744] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.29.111 (http://192.168.29.111:80/dms/device.xml)
Oct 12, 2017 18:33:45.946 [22182] DEBUG - HTTP requesting GET http://192.168.29.111:80/dms/device.xml
Oct 12, 2017 18:33:45.985 [22182] DEBUG - HTTP 200 response from GET http://192.168.29.111:80/dms/device.xml
Oct 12, 2017 18:33:45.991 [22182] DEBUG - DVR:Device: Discovering and refreshing devices.
Oct 12, 2017 18:33:45.993 [22182] DEBUG - DVR:Grabber: HDHomerun discovered a model HDTC-2US.
Oct 12, 2017 18:33:45.993 [22182] DEBUG - HTTP requesting GET http://192.168.29.111:80/discover.json
Oct 12, 2017 18:33:46.008 [22182] DEBUG - HTTP 200 response from GET http://192.168.29.111:80/discover.json
