I already have. Every channel in every tuner is disabled directly on the HDHR web server page. Interestingly though I've just checked on one of the clients and when I go into the tuner source list it is showing some disabled and some favourites. My guess is because it hasnt been enabled it hasn't been syncing? Maybe a eureka moment? No sadly. I synced the favourites/hidden on all the tuners so that every channels showed disabled, but still the wrong damn text appears!
I only have a basic ISP supplied router so I'm not sure if I can do that. It has port forwarding but I can't see anything about port blocking. I'll google it and see if its possible.
Clients don't sync their channels status (favorite/enabled/disabled) beyond their first run. If you modify a channels' state on a client, that client will continue to honor that setting, regardless of what further/later changes you make. (That's why I said you should completely re-install your client apps after making these changes.)
The status of every channel changed to the 
disabled sign when I synced it on the client settings page. It gave me the option to sync from the source (which I chose) or export to the source. This is on android clients.
1 Like
Is the proper disabling of the HDHR tuners something that can be implemented fairly easily/soon?
Despite trying your suggestion of different channel-ids, the channel name problem still exists.
I have searched all of my M3U files for the exact text strings that are appearing as the Channel names and they do not appear in any of them, so the name has to be coming from the supposedly disabled HDHR tuners.
I don't think my router can implement the port blocking or subnet suggestion so if it can't be fixed at your end I may have to give up and go back to the HDHR forced channel numbers.
This is looking like it might be my only option. My tuners are currently connected into the same unmanaged 4 port switch and are allocated reserved IPs in the DCHP table of the main (only) router. If I get a managed switch to replace the unmanaged one how would I set that up so that the tuners can still be accessed via the M3U file/custom source but not by Channels directly? Thanks for any help.
A managed switch is not going to magically make that possible. You need to make the additional subnet in your router, not the switch.
If you do this how will the M3U connect to the HDHR Units? If Channels DVR and HDHR units are in different subnets ?
This is the Same problem I have ...
You create a rule in your router's route table. By default the broadcast packets will not traverse network boundaries, but you craft a rule to allow the DVR to see the tuners across the boundary.
This rule allows all computers on my primary home network/subnet to address the devices on my IOT, camera, and VOIP networks. (Without a reciprocal rule, the devices on those other networks cannot directly initiate, but they can respond to requests initiated from devices on the "Home" network.)
Would be one hell of a lot easier if the devs could just put in an "ignore this IP" or "ignore this device" feature!
or disable autodiscovery like we have under experimental features for Tablo. Autodiscovery uses UDP, so blocking UDP from HDHR IP should work after making sure the DVR server forgets about the device.
You cannot disable auto-discovery. On the HDHR side, there is no option in the firmware. On the Channels side, that is something that is not currently available.
As I've said previously the only real option is to ensure that the broadcast discovery packets do not reach the DVR, either by network segmentation or by blocking the broadcast port with your network's firewall.
Firewall
If you need to configure a port-based firewall:
(not required for Windows Firewall)
Discovery
Allow incoming UDP port 65001 - required for HDHomeRun discovery and for clients to discover the record engine.
I guess blocking Ports 65000-65001 will also prevent HDHomeRun APP/DVR ?
I guess I can try Blocking it on the DVR Server/IP only
Drat, looks like I mis-stated since I was working from memory. Seeing as how that info seems to come from SD's wiki, the port is actually 65001.
(I've edited my previous posts to correct my error. The proper port is 65001/U.)
No big deal I am going to play with this in the Morning I browsed my ASUS router and found where to block the port from 1 IP Address or Multiple.
I'm just wondering if this might be an answer for those, like me, whose router isn't sophisticated enough to do the port blocking.
https://www.cyberciti.biz/faq/iptables-block-port/
Looks like you should be able to use iptables to set a block for UDP 65001 directly on the linux Channels server instance. Will give it a try later and report back.
Eureka! (I think)
So through an SSH terminal to my Raspi OEM server instance I entered
iptables -I INPUT -p udp –dport 65001 -j DROP
iptables-save
you can then check this has worked by entering
iptables -L -n -v | grep -i DROP
which gives you a list of dropped ports. Mine just gave a single line with UDP 65001 in it.
Then I deleted the HDHR tuner(s) devices from Channels with the command(s)
curl -XDELETE http://"IP of Server":8089/devices/"Devicename"
Replace "IP of server" with your server IP obviously and "Devicename" with the HDRH device you want to delete. This is typically something like 1260B381, as displayed on the Channels sources page or the WebUI of the HDHR itself.
The tuners have now disappeared from the sources list and (so far) haven't returned.
Most importantly all my channel names are now correct, so it was 100% the zombie HDHR tuners that were overriding the names.
Nooooooooooooooooo!!!!!!!!!!!!!!!
The tuners have come back!
@tmm1 Any ideas what the hell we need to do the stop the damn things?!!!
the rule to use is (to block incoming packets)
iptables -t raw -I PREROUTING -p udp --sport 65001 -j DROP
Edit:
alternatively (to block outgoing packets)
iptables -t raw -I OUTPUT -p udp --dport 65001 -j DROP
Thanks for that. I have just now tried that too, but have discovered since my first attempt, that neither change to iptables is successfully blocking port 65001.
If I enter the following command on another Linux machine on the same network it connects to port 65001 with no problem unfortunately.
nc -zvu 192.168.1.8 65001
Connection to 192.168.1.8 65001 port [udp/*] succeeded.