This may be a freak thing, but I was scrolling through the new Pluto NFL channel, looking to see which Superbowl replays were coming up. WTH, I have 23 hours of listings for Pluto channels?
When have we ever gotten more than 12 hours? Never, as I recall. Hope this keeps up.
that started at least a couple weeks ago... it was a big suprise!
Ugh, looks like my hourly refresh ditched the extra listings not long after I posted that. Curious what others are seeing.
At the risk of talking to myself, it seems the length of the listings varies with refreshes.
I'm new to channels and am quite impressed. I use the TV Everywhere with our TV provider and really like the automatic commercial skip. I also setup HankLloydRight's PlutoTV no docker links as a "custom channel" and it appears to be working nicely, except.
My problem is the automatic commercial skip doesn't seem to work on the PlutoTV recordings. It appears to have made the edl files but when I play the recording back it doesn't automatically skip. Does anyone have a clue what is causing this? I'm playing back with the channels app in a FireTV stick.
Sounds like your problem is with Commercial Detection. Check out more relevant threads for info on that:
The same problem @jonares had back in December happened to me a few days ago with plutoTV.
~$ ping nocords.xyz
PING nocords.xyz (104.21.96.58) 56(84) bytes of data.
64 bytes from 104.21.96.58 (104.21.96.58): icmp_seq=1 ttl=53 time=9.64 ms
64 bytes from 104.21.96.58 (104.21.96.58): icmp_seq=2 ttl=53 time=9.46 ms
shows no connectivity problem.
Visiting the nocords.xyz site and copying the m3u URL I can download playlist.m3u:
wget https://nocords.xyz/pluto/playlist.m3u
Gets me:
~$ ls -l *.m3u
-rw-rw-r-- 1 wally wally 375363 Jan 28 08:33 playlist.m3u
My TVE channels are still working fine.
Would be nice to know what the i/o timeout value is in Channels DVR.
I got the same transient i/o timeout for the fancybits guide server on a guide fetch this morning
dial tcp: lookup tmsdata.fancybits.co: i/o timeout
lookup means dns, it's trying to connect to your dns server and failing. dns timeouts are usually 1-2s
Thanks. I know that. Wanted to know what the timeout value was since that's also what @Wally_Bkg and @jonares were talking about.
dns is also typically over udp. the error says tcp that means the udp timed out first then it fallbacks to tcp and that failed too. it failed in the dial phase which means the server never responded to the connection request
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.
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
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.
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.