When you try to ping nocords.xyz you’re only hitting a Cloudflare edge node and not the origin server. To test actual connectivity to nocords.xyz to see if it’s up, just go to the website in a browser.
Make SURE your Channels server is on a RESERVED IP address. I setup a new phone for my wife this past week, and last time she turned it on, it grabbed the same IP address as my Channels server. That caused all sorts of issues due to the address conflict. I had to go back into my router settings, re-reserve the IP address for the server, and reboot the wife's phone, then reserve that address so her phone won't go hunting again.
1 Like
When I type nocords.xyz in the address bar of Brave browser using the computer running the Channels DVR server the site comes up fine, although there is a delay of a couple of seconds. Repeating the add source again still gets the timeout error, which since the Ubuntu I use defaults to a "caching" local DNS, so with it freshly in the cache it shouldn't be an issue with the time it takes for a DNS lookup.
doing: dig nocords.xyz gives:
; <<>> DiG 9.10.3-P4-Ubuntu <<>> nocords.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48475
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nocords.xyz. IN A
;; ANSWER SECTION:
nocords.xyz. 300 IN A 172.67.173.152
nocords.xyz. 300 IN A 104.21.96.58
;; Query time: 267 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Tue Jan 30 14:29:04 CST 2024
;; MSG SIZE rcvd: 72
So seems the udp lookup doesn't fail and seems reasonably quick at 267 msec, certainly doesn't account for the delay in Brave opening the page.
I'm still stumped. It had been working fine
1 Like
The computer running my Channels DVR server has been locked to this IP address on my router pretty much since day I installed Ubuntu 16.04 on it, i.e. many years. and it hasn't changed. Still at 192.168.1.73, if it wasn't the webpage on my wife's computer we use to view the guide and select the recording wouldn't work: http://192.168.1.73:8089/admin/settings/sources
Since it seems that you’re the only one having this issue, it has to be a local config, network, or DNS problem.
Not familiar with Ubuntu, but can you clear its local DNS cache and try again?
Another user had to reboot their NAS for the same issue with FrndlyTV Frndly TV for Channels - #971 by mexicanmamba
I had a log entry showing DNS lookup timing out after 5 seconds (transient) [ERR] No stations available in lineup X-M3U during guide data download - #2 by chDVRuser
P.S. nocords.xyz opens in Brave here in less than one second.
Reboot did nothing. Since Brave works there is noting wrong with DNS or Networking. Question is what could be screwed up in the Channels DVR setup to cause the problem?
For reference, I was playing with the source->settings for plutoTV to try and change the pluto numbers 9000+ to something < 6000 for the TVE channels. While doing this my Internet provider had an outage, and all the ongoing activity on this old Ubuntu 16.04 eventually crashed it. When I rebooted the plutoTV source was broken.
Just as a point of reference, I added Pluto to one of my Channels DVR docker container Sources.
Brave browser dev tools shows it took the server 2.10 seconds to add the source using the PUT method.
2024/01/30 15:46:23.177429 [M3U] Refreshed lineup for PlutoforChannelsnocords with 372 channels
2024/01/30 15:46:25.258441 [DVR] Fetched guide data for XMLTV-PlutoforChannelsnocords in 453ms
2024/01/30 15:46:43.144376 [DVR] Indexed 11763 airings into XMLTV-PlutoforChannelsnocords (372 channels over 30h0m0s) + 217 skipped [16s index]
2024/01/30 15:46:43.158688 [DVR] pruned 162 replaced airings in 14ms.
2024/01/30 15:46:43.311299 [IDX] Pruned 14 expired groups from XMLTV-PlutoforChannelsnocords in 22ms.
1 Like
Just for grins I added
104.21.96.58 nocords.xyz
to /etc/hosts
And then plutoTV started working. Clearly Channels DVD needs some way to lengthen the "timeout" value for DNS lookups.
As I said above, that IP address is a Cloudflare Edge node for their reverse proxy network and not an address to the origin server. I would advise not to add it to your hosts file to bypass your own local faulty/slow DNS. Cloudflare can and frequently changes their edge servers and the DNS for nocords.xyz can and does change all the time. As soon as it changes, your little hack will stop working. You've put a band-aid on the problem, but you haven't actually fixed the problem, which is clearly your local DNS. ("It's always DNS.")
2 Likes
I can't fix any problem with my Internet provider's DNS. From their point of view the problem is Channels DVR code for not waiting long enough since it does work if you wait a bit more.
I'm still on the Channels DVR "free trial" with all the uncertainty of ATSC 3.0 I suspect this solution is not really viable for us.
Here is my "break out" of potential savings from "cord cutting":
My wife demands all the "premium" movie channels that U-Verse offers except MGM+/Epix (they have a "free trial" weekend three or four times a year, with their limited catalog she can record all they have that she wants during these trials). We pay $270/month (after this month's $11 increase) it breaks out like this:
GB fiber Internet $65
U-Verse U300 $150
Taxes & fees (DVR box rental, local channel access, etc). $55
We can get all her premium channels with streaming (we can stream them now as part of U-Verse):
HBO Max $16/month, or $20/month for their 4K content.
Showtime/Paramont+ $12/month or $120/year
Starz $10/month
CineMax $10/month
Dropping U-Verse we'd have:
$70 GB fiber Internet (lose a $5 "bundle discount" we have now)
$48 or $54 per month for the premium streaming.
A potential savings of ~$150/month minus what it takes for local channels and DVR
IF I can find a good OTA antenna and location for it, Channels DVR and HDHR would be the cheapest solution, ignoring the initial cost for HDHR box and antenna at $8/month for Channels DVR for a saving of $142/month after the equipment is paid for. But with the ATSC 3.0 situation buying an HDHR may not be a good long term move unless simucast of ATSC 1.0 ends up being mandated.
Plan B gets local channels with a "cloud DVR":
- YouTubeTV $73/month (my brother-in-law does this.
- DirectTV Stream $80/month + tax for the base package (my neighbor does this)
Going plan B cuts the potential monthly savings in half.
I'll mess around with the OTA antenna issue a bit more while the free trial is in effect, but it is not rocket science to run a cron job to update the /etc/hosts entries for nocords.xyz once a day or after a periodic nslookup specifying the nameserver to avoid /etc/hosts usage. So it is not as much of a "hack" as what is likely going on inside of Channels DVR and/or nocords.xyz
Have you just tried using another DNS? There are many alternatives that may perform better than your Internet provider's, for free.
I'm not sure if your math includes this, but FWIW, your Plan B still requires you to have a $65+ internet subscription. Seems obvious, but I'm just making sure you're comparing apples to apples before making a decision!
1 Like
That is the $70 for GB fiber Internet mentioned at the start of the "Dropping U-Verse" paragraph which makes the maximum savings be $200 instead of $270.
All streaming has this issue including Channels DVR unless you only use OTA and the HRHD box can provide the channel guides from the OTA channels (I don't know if it can do this since I don't have one).
1 Like
This topic should probably be split, I don't think it has to do with nocords in particular. It seems a DNS issue on your network/host.
In any case, 267 milliseconds to a localhost nameserver is quite high, even considering this answer not being from cache - and esp. considering your low latency ping. mine returns in 4ms uncached and 0ms cached. Obviously Channels shouldn't time out at <=267ms, but it points to a place to investigate.
Can you run this command again, at least twice, so that the 2nd answer should come from cache? is 267ms a rather constant response time? Does it get even higher?
assuming any firewalls are configured to allow dns responses from the internet:
After doing that, try dig +trace nocords.xyz | grep Received. The response times that the dig client gets from the name servers are interesting.
Then, try dig +norecurse @ingrid.ns.cloudflare.com nocords.xyz | grep time:. This will ignore your local stuff and get the answer straight from the source. If this answer is fast, the issue is likely how your local nameserver is configured/behaving. I would experiment with not using the localhost nameserver and using your ISP's or Cloudflare's* directly. I don't use Ubuntu (or any systemd) but I think this blog or this thread is a good place to start.
1 Like
With my /etc/hosts hack I get:
~$ dig +trace nocords.xyz | grep Received
;; Received 28 bytes from 127.0.1.1#53(127.0.1.1) in 2 ms
~$ dig +trace nocords.xyz | grep Received
;; Received 28 bytes from 127.0.1.1#53(127.0.1.1) in 1 ms
~$ dig +norecurse @ingrid.ns.cloudflare.com nocords.xyz | grep time:
;; Query time: 13 msec
This box was available to test Channels DVR. Ubuntu 16.04 is basically out of support, which is fine for what I keep it for -- running Windows virtual machines to support projects I'd worked on before I retired. I need it a couple of times a year to pick up a small side gig. I'm not spending anymore time trying to fix an old box, my /etc/hosts solution will let be use it enough during the free trial to see if it is a viable solution for us and worth $8/month. I'm close to considering $8 a month worth it for the automatic commercial skip, my wife however is confused by the whole thing and her eyes glaze over when I try to explain it.
On my i9 Ubuntu 22.04 box doing this gets:
~$ dig +trace nocords.xyz | grep Received
;; Received 503 bytes from 127.0.0.53#53(127.0.0.53) in 8 ms
;; Received 667 bytes from 199.7.83.42#53(l.root-servers.net) in 24 ms
;; Received 609 bytes from 212.18.248.42#53(z.nic.xyz) in 88 ms
;; Received 72 bytes from 108.162.193.225#53(ram.ns.cloudflare.com) in 12 ms
So clearly something with the old 16.04 box is fubar. My point is if the Channels DVR DNS timeout was adjustable in the settings this issue would never come up. Who cares about a 5 second delay updating the program guide once a day?
1 Like
Personally, I turned OFF automatic skip a long time ago, when it consistently skipped way too much show. Very few shows mark commercials properly and perfectly. Though, some do, but not enough to leave autoskip running for me.
1 Like
The Britbox Mysteries channel guide data has had an issue since 1 Feb. Any ideas how I can resolve the following issue?
The Britbox Mysteries stopped displaying season/episode numbers and it will not tell me if I recorded the episode already. Also, some programs received a new Series ID, so now I have 3 Series IDs for the same program. One recorded OTA, and two from PlutoTV.
I'm sure that nocords is just pulling the data from PlutoTV, so is there some way I can tell ChannelsDVR to reassign the Series ID and look up the episode name to correlate to the season and episode number? Thanks.
As you found, the issue is the Pluto guide data (not great) and they have their own unique series ID's.
The only way to match them up with Channels DVR guide data and recordings is to move the Pluto recordings into local content import and import them. That won't help future recording from Pluto though.
I tried it once and gave up.
Thanks.
I guess this is a case of “you get what you pay for” LOL
1 Like
This is why I map Pluto channels with the guide from Channels to avoid stuff like this. It is a cluster to deal with. Only other method is to use tmm or filebot to deal with the mess...
1 Like