Not sure what this functionality is supposed to accomplish with dvr clients. I have Tuner Sharing ON and all devices perform tuner searches and have Scan network for tuners/Add Tuner under Manage sources available even when connecting remotely. Seems like a feature from the paid app sneaked into the DVR version.
You don't. If you don't want your client devices to find tuners on your network, then you need to partition your network or use a firewall or packet filter to limit what the clients see.
2 Likes
When I am streaming remotely I do not want my device to be snooping for local tuners and the DVR. My intentions are clear and somehow the client does not follow.
Then use a guest wifi network with no access to the local network, just the internet.
If this is an extension of your attempt to force "remote" connections locally using a reverse proxy, then you have moved your configuration outside of support. When you modify the defaults and basics to no longer resemble a supported configuration, the expectation is that if you can create and maintain that configuration, it is up to yourself to support issues with it when things go wrong.
Sounds like you might want to look into a router that will allow you to set up some ACL's with some white listed IPs. You could do do this via a ACL or protect list. I mean if are really concerned you could always turn of remote access and use a tunnel into your network and appear local and then you wouldn't be remote.
First you need to know this necessary ... There should be some control on the client of how sneaky it needs to be when second guessing user choices.
Yea, I have remote access disabled, and use Wireguard VPN when remote to connect and stream.
Based on your many posts complaining about almost every aspect of Channels I don’t know why you continue to use it. Why not write your own program and leave behind this program you clearly don’t like? For some reason you keep expecting the developers to rewrite their code to fit your very specific and unnecessary needs. As written, it works at home, it works away from home. It updates itself and cleans up recordings when you are done. Basically it works out of the box as written for 99.9% of its user base.
2 Likes
Little criticism never hurts anybody. I think the product is wonderful. Just a few glitches here and there.
Why not write your own program and leave behind this program you clearly don’t like?
You clearly have no idea about the amount of effort going into software development effort going into product of this size. It might be easier to open your own bank.
Actually I do. My coding goes back to assembly language days. Never assume anything about people you don’t know. My point is if you have so many ideas about how a program would better suit your needs, and none are doing it, then write your own. Don’t know how? Then learn and then maybe you will understand why the “constructive criticism” you keep giving out is falling flat in this forum. The program is designed to work for the masses, for the expert and novice alike. So again, don’t like it, write your own, put it out there for sale and make some money.
2 Likes
Do the clients always scan networks like this? Even when I connect to someone else's wifi, or the hotel? Could it become a problem, where the IT folks might see this activity and find it to be a problem?
No, the clients aren't scanning the network. It is actually the HDHomeRun tuners that are sending out broadcast packets, and the clients are responding to the broadcasts.
In short, the tuners are announcing their presence, and Channels is responding to that. If you don't want that behavior, you need to block the HDHomeRun tuners. Channels is not the misbehaving program, but rather with how SiliconDust has implemented their hardware.
1 Like
I kinda agree with you.. It's not like its legal to nmap a network without permission so asking a company to protect their app from illegal activity seems kind of odd. I don't think channels is offering any kind of bounty hunting if they find an exploit so not sure where all this is coming from. We don't even know if it's an issue or if it's just some request that isn't going to support but one user. if that's the case, i vote the dev team focuses changes that will help the many vs a single use case.
Wait a moment. So if the issue exist when channels isn't even installed then why would it be requested that channels fixes this issue.
2 Likes
and you are saying this based on .... ?
It doesn't sound like your preferences and expectations for our software line up with our target customer base.
Always discovering local HDHomeRun's has been an intentional part of our product since the start. It's something that is used by customers who are accessing a DVR remotely and also have local HDHomeRun's they want to use.
It sounds like things veered off the tracks a little bit here. There's no network scanning or an nmap of the network happening. It's standard Service Discovery.
You can review the HDHomeRun discovery process here:
3 Likes
Ok, I think the problem here comes from the discovery process and an overloaded endpoint - /status
- When coming from an internal network it gets the stats
- Coming from an external network it returns 302 to /oauth/start/auto
- When proxying and setting the header X-DVR-ForceAuth is set the DVR replies with a 200 and a form for manual authorization which throws a monkey wrench in the authorization process of the new clients.
I worked around this problem by checking the user agent for now and issuing a manual redirect if this is 'Channels Cloud'
I think using separate endpoints for Channels Cloud and clients would take care of this problem?
No comment 
This is an unsupported configuration. If you use the product as intended, there are no problems or "monkey wrenches".
Ignorance is bliss
Turn off remote access and use a VPN. "Problem" solved. You are blowing up this forum with your issues with unsupported configurations. Use the software as intended or save your $8 a month and go with another product.
1 Like