DVR Can't Find HDHR Tuner Following Update

Channels DVR Server Troubleshooting
#1

Our DVR is completely out-to-lunch.

2018/11/20 20:09:20 [SYS] Shutting down for upgrade from v2018.10.08.2134 to v2018.11.20.2224

After that: Nothing but error-after-error in the log.

2018/11/20 20:09:27 [NAT] Failed to discover upnp: write udp4 0.0.0.0:35962->239.255.255.250:1900: i/o timeout 2018/11/20 20:09:27 [NAT] Failed to discover router using natpmp and upnp. 2018/11/20 20:12:17 [DVR] Error during search: cannot perform operation on empty alias 2018/11/20 20:15:00 [DVR] Deleting /volume1/channels-dvr/TV/Jeopardy!/Jeopardy! S35E51 2018-11-19 Teen Tournament 2018-11-19-1930.mpg 2018/11/20 21:00:00 [DVR] Starting job 1542765600-28 Home Improvement on ch=[7.3] 2018/11/20 21:00:00 [DVR] Waiting 29m59.99376461s until next job 1542767400-28 Home Improvement 2018/11/20 21:00:00 [DVR] Error running job 1542765600-28 Home Improvement: no hdhomerun found

Stopped and restarted the DVR. No joy.

The apps on the mobile devices can see the HDHR just fine. So can browsers. (It has a static address obtained from DHCP, btw.)

#2

Update: I just added the tuner manually, by IP address, and everything's back.

Whatever you did, devs, suggest you undo it.

#3

bump Any idea what happened, here?

#4

This was a minor bug fix release with no changes to the HDHR code. No one else has reported problems so I assume some sort of network fluke?

#5

Last evening my remote access stopped working. After trying it on several devices, I came to the conclusion the problem was Channels and not my setup (as I was still able to remotely access other services both at the site and on the same machine running Channels). Furthering that assessment was the notice that the Channels server version had been bumped. (BTW, is there a way to disable the server from updating itself?)

I haven't had the time to parse through the server's logs to see what errors might be contained therein, but when I get a chance I will. Since my issue is in regards to remote access, I'm not sure if it's directly related to the OP. As I'm away from home at the moment, I can't get into too much troubleshooting. In any case, I wanted to add a "+1" to this issue as it seems to have possibly affected me too.

#6

I noticed that, but I generally don't have "network flukes." And, as I noted, everything else was able to "see" the tuner.

If I hit the drop-down and choose "Scan Network," will it drop the manually-added tuner and start from scratch?

#7

No it won't clear anything out. Also once you enter an IP it remembers it and always tries to connect directly after restart, which means it can find it more reliably in case the broadcast UDP method fails.

#8

Two enhancement requests: 1. Ability to tell it to forget that and go back to the broadcast UDP method. 2. Ability to enter a hostname, as well as an IP address.

Shouldn't require any new buttons or dialogues. "Scan Network" can tell it to forget manually entered data. "Add Tuner Manually" dialogue could accept IP addresses or fully-qualified hostnames.

Thanks!

#9

New DVR version (should finish building in 10 minutes) has two new APIs:

DELETE /devices?ip=1.1.1.1 will forget any manually entered IPs. You can verify on /settings by looking for device.manual.xxxxx

DELETE /devices/<device_id> will forcibly remove the tuner from the DVR so you can test re-scan.

Hostname resolution is out of scope. libhdhomerun only works with IPs, and DNS/mDNS resolution adds several layers of complexity.

Multiuser DVR (Replace TiVos)
#10

I've no idea whatsoever what that means.

Too bad about hostname resolution :frowning:

#11

i.e. curl -XDELETE http://n.a.s:8089/devices?ip=h.d.h.r

1 Like
#12

Figured it out.

Forced an update. Ran the curl command. Still had the tuner. Stopped and restarted the process from the Synology DSM's package manager. Couldn't find the tuner again. "Hmmm..." Started to write "Dunno what to tell you, because nothing's changed here..." when I thought "I did readdress the network & squeezed it down."

Checked the network config on the NAS. Sure enough: The NAS had failed to pick up the new netmask during any of the multiple DHCP renews since the network readdressing more than two weeks ago. (This is a bug I shall report to Synology.) Rebooted the NAS. Now it has the correct netmask (and broadcast address). And now the DVR software finds the tuner on its own, again.

Mystery solved.

1 Like
#13

Nice sleuthing. The libhdhomerun discovery process sends out a UDP broadcast depending on the netmask so that explains why an incorrect netmask would cause issues.

1 Like
#14

I'm replying to my previous post here regarding loss of remote access after the 2018.11.20 update. After spending over a week bashing my head against the wall trying to figure out what changed, why I couldn't access the server remotely, and why the logs didn't show any useful information, I found the solution. For some reason, my router did not have port-forward setup to route access to the Channels server. Whether the rule was somehow deleted, or more likely that Channels was operating fine previously without the need for such a rule, there now exists such a rule and remote access to Channels is once again restored.

In any case, the API endpoints for manually removing devices are appreciated.

#15

The DVR tries to auto-renew a rule every few hours using NAT-PMP or UPNP but those are not very reliable, and I have often seen routers get into weird states where the automatic rule disappears until you reboot the router.

For best results, keep the DVR in "manual" mode and just add the rule to the router directly.

1 Like
#16

That was the strangest part: it was set for manual forwarding. I don't use NAT-PMP or UPnP, which is why I had thought the rule was already set. In any case, it's back working, which is a good thing. (I evaluated Emby and Plex for remote DVR capabilities, and both fell short.)