Had this happen a few weeks ago, thought it was my DNS filter, but it's started doing it again where the Viacom channels will not load to the point of a "Time out: 32sec". Other times it will load the channel, but after a few minutes will pause as if buffering, then time out. Does this no matter which client I'm using. I've checked my DNS logs and nothing is being blocked. Watching directly on the Viacom sites works flawlessly.
I'll submit logs, just let me know which ones to submit.
is this a timeout while recording or on connection?
DNS filtering is a great way to protect users computers, it might be best to leave your DVR and tuners alone or point them to a reliable and safe DNS source such as google DNS or OPEN DNS.
Any word on this?
Does it happen if you use your ISP dns? Usually always related to DNS issues.
Not DNS this time. Logs have been submitted as 9c260bf1-49ee-4fdb-809a-4ffc4d79f4e3 .
Also submitted AppleTV logs.
There's some issue on your network. If its not DNS then its a latency/throughput problem. But my guess is DNS related. If you're using some cloud-based DNS as your upstream, it will end up sending you to a video CDN that's not near you. It is recommended to use your ISP DNS servers.
From your logs:
at=2022-01-24T17:55:16.598983-07:00 tag="espn1" action="fetch" url="https://x-live-espn-stgec.uplynk.com/..." duration=2.048 content_length=1931712 encrypted=true remuxing=true timedout="bodyTimer" downloaded_length=851968 failed="temporary" failed_while="reading" err="hls: timeout while waiting for data" first_byte_time="8.230658625s" last_byte_time="17.896811s" max_read_time="763.891709ms" body_time="16.391699917s" time="17.896852s" status="segmentTemporarilyFailed"
This is saying it tried to download 2.048s of video, which was 1.93mb on the video CDN
It took 8.2s before the download even started, and then at 17s it gave up after only downloading 851kb (less than half) of that 2s clip.
I guess you could try comparing what happens in the ESPN app or website.
I didn't notice any issues with ESPN, this issue is predominantly with Viacom stations. Streaming directly through the website never gives issues, which makes me think it's not the DNS.
I would need to see diagnostics from the DVR while its happening with that other channel, then. But your logs are showing pretty bad issues with espn, so I can't imagine its any better or different on other channels.
Logs submitted were from when it was happening. Here are new ones where it's happening again right now.
Logs have been submitted as 7ce2d611-571b-40c9-b260-f2c6623b8313 .
Same story:
at=2022-01-24T18:12:04.418868-07:00 tag="mtv" action="fetch" url="https://x-viacom-stgec.uplynk.com/ausw/..." duration=2.048 content_length=975168 encrypted=true remuxing=true ad_detected="uplynk" timedout="readTimer" downloaded_length=163840 failed="temporary" failed_while="reading" err="hls: timeout while waiting for data" first_byte_time="4.836426291s" last_byte_time="6.84243575s" max_read_time="2.0058085s" body_time="5.709380042s" time="6.842474083s" status="segmentTemporarilyFailed"
600kb out of 900kb downloaded after 6.8s. The fact that it takes almost 5s for the download to even begin makes me think you have some kind of proxy sitting between you and the internet.
Or maybe your router just needs a reboot.
Like I said before, the first step would be to try switching to ISP DNS servers.
Both mtv and espn1 are coming from uplynk.com CDN so atleast that part makes sense that both channels are acting the same way.
Yea but what IP is it resolving to. If it's sending you to the IP of a server that's halfway across the world, then ofcourse its going to be slow. When you use ISP DNS it resolves to the IP of a server that's in the ISP datacenter, which is only a few milliseconds from you.
If you want help you're going to have to be more explicit about what kind of DNS system you're using and how your network is setup. From your screenshot it appears to be intercepting HTTPS as well, which would explain some of the delays shown in our logs. It's also resolving AAAA so its possible you're seeing slowness streaming over ipv6 and your browser is only using ipv4.
The HTTPS were me testing MTV from my browser. I'm using NextDNS as the filter, but they resolve to the closest location, which for me is Denver. Here's my ping to their server - averaging 16ms RTT. And yes, I have set up IPv6, but that wouldn't cause this issue.
I don't know what's going on either, just making guesses.
You can view the logs yourself at x:8089/log/hls and search for err=
Maybe try curling the url that's failing/slow and see what kind of speeds you get:
Does the Activity Monitor on your mac show cpu, ram or disk approaching 100%?
No, CPU < 2%, Memory 30% free (using 5.15/8GB), main hdd has 142 GB free, DVR hdd has 21TB free.
Seems simple enough to switch from NextDNS to ISP dns just to rule it out especially since so many have mentioned it. CDN IP pools are so huge you never know what may be inadvertently filtered when using a filter service even if it’s only set to filter malicious, etc. Not to mention the routing algos - geographic proximity is likely not the only thing in play and you could, as previously mentioned, with ISP dns end up getting served from a server with a cross connect in the same data center vs something that may need a much further route than you’d think due to lack of efficient peering etc.
