Cannot remove HDHomeRun from source menu

this....

If you run Channels DVR in a docker container using a bridge network, then your HDHR devices won't appear since their broadcast traffic won't be seen on the bridge network.

You can add an HDHR by specifying its IP address though.

Here's what I did.
In Docker, created a user defined bridge network cdvr-net subnet 172.18.0.0/16 gateway 172.18.0.1

In the docker run command, I specified using the cdvr-net bridge network and to bind it to my LAN1 interface at 192.168.1.4
--network=cdvr-net -p 192.168.1.4:8089:8089/tcp

Haven't tried yet, but assume a channels client can't see the dvr and you would have to specify the dvr server ip address in the client (in my case 192.168.1.4).

I'm running Channels DVR in three containers.
One for Pluto (notice no HDHR found)
Screenshot 2021-07-08 at 13-54-24 Channels Settings
One for TVE (notice no HDHR found)
Screenshot 2021-07-08 at 13-54-53 Channels Settings
One for my HDHR Prime (added by IP address)
Screenshot 2021-07-08 at 13-55-08 Channels Settings

How does that address the Priority on the Clients that are not in a docker ... they each discover the tuners differently.

I appreciate you posting that but that is way too much of a hassle for something that should be controlled at the server.

I only posted that running in a container is a workaround for people that are "annoyed" by an HDHR source showing up in their DVR sources. Even though that source isn't used if it's not assigned a provider and postal code.

Has nothing to do with client devices.

I fully understand ... but the way channels is designed if you have multiple HDHR devices ... there is no way to set the tuner priorities across all devices at first time startup at the very least. I have multiple HDHomerun Devices and multiple clients ... and when I want to disable a device on all clients I have to do it 1 by 1.

Also tuner sharing totally goes out the window if you have multiple HDHR devices and the Clients are not set to the same priority.

Network segmentation would work... but it's not a viable solution for something that could arguably be native functionality. I run ChannelsDVR server natively on my synology to take advantage of Intel QS.

Really surprised that the idea of specifying HDHR IP and determining whether or not you want it present in ChannelsDVR is so trivial.

I've created a Feature Request for this.

1 Like

any chance there's some traction with this?

Here's an instance in which a tuner should NOT be auto-discovered again, but I can't remove it.

I understand what you're saying, and I've read it here several times.

  • This is a tuner that it should NOT re-add because it's not in the same network.
  • I can't just IGNORE the tuner because the person that I'm teaching to edit channels lists gets confused be see TWO tuners where there should be only ONE.
  • And, UNPLUGGING the tuner doesn't work because it's still in use on another network where it IS the correct tuner.

Then your network is allowing the tuner's broadcasts to span network boundaries. You would need to create a firewall rule on your router to block them, or remove the rule that's permitting them.

(Discovery is done via 65001/UDP, IIRC.)

What is the scope of scope of auto discovery? Local network with the interface?

I assume it's local, as it does not traverse network boundaries normally. (I use a broadcast relay to forward certain packets across subnets here, as I've never had HDHR discovery happen across networks without manual intervention.)

Have you restarted the DVR server since changing its network? Does it still any interfaces on 192.168.25/24?

I would assume local as well. I have had to use broadcast relays, thankfully not in this case.

Been restarted several times.

No, doesn't have an interface on that network. That network is still reachable, but that doesn't matter either. Since it was auto-added, not manually added via an IP address, there is no mechanism to remove it short of wiping it clean and starting over.

I have forced the old network to be unreachable, for what it's worth, and the above still applies.

Have you done that bi-directionally? It seems to me that if the DVR cannot access 192.168.25/24, then the broadcast packets being sent from the tuner are somehow finding their way from 192.168.25/24 → 192.168.1/24.

All that assuming the netmask is correct

1 Like

I'm guessing you added manually by IP at some point and it's being remembered.

There is a curl command to forget the IP.

I still plan to add remove/hide button to the UI. It's just tricky with all the details. If I hide by IP and the IP changes, the HDHR would appear again randomly. If I hide by device ID then we still need a way to unhide or readd the tuner back.

1 Like

That'll work. Are these documented somewhere?

I don't think I ever manually added it. I love than Channels CAN scan for these, in my own use case I'd prefer to be offered a newly found source and have the option to check a box to add it, not have it added automatically.

As I said way up there earlier today, when it found the (later offensive) HDHomeRun, it WAS on the same network with that tuner. I believe it was autodiscovered. Then it was moved to another subnet with another HDHomeRun which it also discovered and added. But since it still had a record of the first one and could reach it over a routed network I couldn't find a way to get it to forget it.

And, please know, I love this product. Anytime I show it to new people, the reaction is always, "why did it take so long for somebody to build this!?"

If the tuner was manually added by IP address, wouldn't that show in the settings json as
"device.manual.192.168.25.101": "true"

To remove it
curl -XDELETE http://ip-of-dvr:8189/devices?ip=192.168.25.101

If it wasn't manually added, remove it with
curl -XDELETE http://ip-of-dvr:8189/devices/<device_id>
In your case curl -XDELETE http://ip-of-dvr:8189/devices/10A06481
Then restart Channels DVR

This isn't really a network thing.

It's a thing about what Channels does when it initiates or reinitiates and decisions made about auto-discovered items.

What I don't know for a fact, but believe to be true from reading many posts here: