Saw when running troubleshooting that an alert came up saying that Cloudfire DNS could cause issues with TVE. After switching over to Google, I get the same alert for them. Considering these are the two most popular options - which DNS does Channels recommend using? Related comment, what sort of TVE issues have you seen with these DNS selections? Thanks.
Using the DNS servers that come from your ISP has given the best results.
I've had good results with NextDNS. Just don't go too crazy with the ad-block lists. They're also embedded within carriers' networks in major metropolitan areas — minimizing hops and delivering "unbeatably low latency at the edge." This helps mitigate the issues that Channels faces with incorrect CDN. Here's a speed comparison for your reference. Firefox is even using them in their browser now.
fyi, ive been running my own unbound dns servers locally for years without any issues but the troubleshooter is saying that i am using cloudfare. bug? thanks
Are you sure it’s doing its own recursive resolving or is it actually falling back to cloudflare? Maybe via DoH?
I’m pretty sure. I’m going to have to check now. Thanks.
thanks for the push to check, guessing one of the updates to the container i was using turned on forwarding to cloudflare. all is good now, green check marks everywhere.
I will say that it is good to use your ISP's DNS servers if you have a good ISP, but it is not a solution across the board.
Sometimes, your ISP's DNS servers are unreliable to the point where they go down for hours at a time each month. I have to use a DNS forwarded/proxy on my firewall and cache results from my ISP, Cloudflare, and Google. Cloudflare and Google actually respond to lookups quicker than my ISP's DNS servers, and while they might not provide the exact 'pathing' my ISP would prefer to route my traffic to, they are so horrible I don't really trust them to route my traffic efficiently anyways. When the ISP's DNS servers are down, you internet doesn't work until you start sending requests to other DNS servers.
I've not had an issue with running Channels on this network or a remote network on a better ISP and using their servers, but I would think it would be good to identify the issues with why it has issues using more generalized DNS and working around that.
I live in the area where cable TV was invented, because we were in a valley sheltered from 2 major broadcast areas, and people started putting antennas up on ridgelines and then running cables down to the valley to distribute the signal. It was a natural place for early cable providers to get involved. Unfortunately, over the years they strengthened their contracts with the local municipalities to the point where even the likes of Comcast and Verizon don't want to enter the market for the costs they will incur, and all of the residents here are left with the worst internet I have ever seen for an urban area (and I work for a company that has employees all over the country).
We also have expensive cable TV plans for horrible channel packages, stream quality, and set-top-box hardware and software. My cable box 5 years ago, if I wanted to watch video on demand, made me watch a 45 second video that looked like the into to an AMC movie in 1995 (rollercoaster made out of film).
Point being, people can't control their ISP's DNS, and it might be horrible, and these same people might likely be cord cutters who have to rely on third party DNS. Even some info as to why it 'doesn't work' would help people with networking knowledge work around issues.
This is the only other conversation about it that I recall seeing. Would be nice to have a writeup put into the Knowledge Articles area so anyone with the same questions could be referred there.
Google’s DNS worked fine for me but I switched to Quad9 about a month ago for better privacy and threat protection and have not had any issues.
Are there issues with ChannelsDVR behind a pi-hole proxy?
I have all my devices going thru NextDNS. They support a type of private EDNS so the CDN's do know where I am just not who I am. They are much more reliable than my ISP and faster. Ping to the NextDNS servers in Atlanta from me in Nashville is 15ms. My ISP has its DNS all over the country and many times I am connecting to the server in Los Angeles.
Shouldn't be, but if you do find issues please let me know. (I'm dschaper (Dan Schaper) · GitHub)
You can also set up a group with all of the lists disabled and put the Channels server in that group.
Also, you can check the status of things by running the Troubleshooting steps on the admin interface under Support > Troubleshooting and then when the process is done you can check the logs under Support > Logs where you will see entries for
ad-dns for the domains that Channels needs to resolve correctly.
Yeah, I have tailed the TVE logs when enabling YTTV TVE and local TVE and note quite a few ERR_NAME_NOT_RESOLVED logged, probably due to pi-hole. @dschaper kudos for pi-hole, btw. Not sure if that is a real issue or not. I disabled pi-hole while running a reauth and scan, and this mitigates it somewhat.
YTTV an TVE auth process for groups of channels and locals is getting more complicated day by day with each seeming to want to be individually authed outside Channels. I still don't have a working TVE for Fox channels in my dfw market and have to rely on a HDHR.
The best thing for stability and sanity is to not have any kind of blocking on Channels, there's no real reason to block for Channels and only potential issues and downsides.
I've created a group for Streaming and added the Channels server to that group. None of the adlists are applied to that group. I do have some blocking enabled on the streaming devices directly (Apple TV and some really obnoxiously chatty Amazon/Google boxen) and have not seen any issues with those being neutered.
Yes, I understand. The rub is the dvr(s) here aren't completely dedicated to Channels and can run other things that might benefit from pi-hole.
Ah, yeah, I run everything in containers, docker/lxc/kvm, with networking that allows each server and service to have it's own IP address or some way to isolate the service.
This is good timing for me since I just deployed a pi-hole on my system yesterday. I never thought of the implications of the blocking on a reauth. Probably saved me many troubleshooting hours when I eventually had to reauth and forgot I had pi-hole running.