Danny. I saw up the thread that you mentioned this only happens when viewing recordings. Is that still true? If so, in your client settings do you have tuner sharing enabled or disabled?
It's a bit maddening how everyone is so quick to continuously blame the network and not even consider the fact that it could be something within the app or tvOS itself.
Just because this isn't a widespread issue doesn't mean that there isn't a bug or something somewhere in Channels or tvOS causing these intermittent buffering issues for users with specific configurations.
Even if there is a temporary network glitch, Channels should be able to recover and resume the stream afterwards without having to fully reboot the ATV. As I mentioned earlier in the thread, the network activity from the DVR service on my server is virtually nil (Windows Resource Monitor shows about ~130,000 B/sec for channels-dvr.exe to the ATV) when the issue occurs.
I thought I'd found something promising, which is why I've held off on posting this week until now. I setup NIC teaming using the native Windows teaming capabilities on Tuesday night with my server's dual onboard NICs. I went almost three days before experiencing it again just a little while ago.
I looked at the logging as described earlier in the thread, and I'm seeing the same thing as Danny. My cache reaches 0 and bombs out.
Running the speed test from the DVR server, I regularly get between 875 Mbps and 950 Mbps download with less than 3 ms latency and jitter ranging from .3 ms to .75 ms.
What's interesting is that if I kick off the speed test when I'm experiencing the issue, Channels almost immediately resumes the stream, and it keeps working for a few minutes before the cache runs out again. I was able to reproduce this behavior consistently the 4 or 5 times I tried it.
I also had ping -t running from my desktop PC to the DVR server this last time when I kept running into the issue. 1365 packets sent, 0 dropped, max latency 12ms, and average latency 0ms.
But, ultimately, once the issue occurs, it keeps happening every few minutes until I reboot the ATV, where I might not see it for a day or three. If this issue had something to do with my network performance, why would it clear up for days at a time and only after the ATV was rebooted?
My configuration for Channels isn't super complex. I have a brand new HPE Microserver with a vanilla install of Windows on it that was purchased specifically for use as a DVR/storage server. There's absolutely nothing else on the server at the moment other than the Channels DVR software.
Everything is hardwired with CAT6 into a network that's comprised of three HPE managed gigabit switches, each of which are all interconnected with bonded gig trunks. I don't use any of the traffic manipulation features on the switch...no QoS, no flow control, no jumbo frames, no storm control, etc. I have loop protection and RSTP with the bridge priorities set appropriately on all switches.
I do have VLANs on my network, but those are all handled at the router. All the Channels/TV traffic is on the same default, untagged VLAN, so the router doesn't come into the equation at all.
I'm not experiencing stuttering issues with any other apps on my ATVs or anywhere else in my network, and the Channels DVR is able to record multiple TV streams simultaneously without missing a beat.
Speaking to that effect, last night, I had five streams recording simultaneously, was watching a recording on the ATV, and had another recording playing via the browser. Everything worked without issue.
These are the things that I've already tried...
- updated the BIOS
- installed the latest chipset drivers, graphics drivers, NIC drivers (tried both the HPE branded and Broadcom drivers), and NIC BIOS
- set the power policy in Windows to high performance
- adjusted multiple settings for the NIC, including changing the EEE profile, disabling EEE, adjusting the number of RSS queues, disabling flow control, and adjusting the receive and transmit buffer values
- put in AV scanning exclusions for Channels into Windows Defender and even disabled Windows Defender
- tried the production and multiple beta versions of both the DVR software and Channels apps
- unplugged the ethernet cables from both the ATV and the DVR server when the issue was occurring
- tried a different switch port, different cable, NIC teaming
What more can I do? And why isn't the app recovering the stream if there's some sort of temporary network glitch? The speed test and ping tests that I'm running when the issue occurs proves to me that there's not a line quality issue when the issue is occurring. All of the evidence I'm seeing is pointing me to the ATV or app itself.
We've definitely considered it could be within the app or tvOS. We just haven't found anything that pointed to any of that.
We have a few different people on this thread and so far have seen at least two distinct issues that have different behaviors in the logs.
To try to see if there is something strange going on with the network that we can work around, please try the tvOS TestFlight beta and scroll to the bottom of the Settings screen and enable Use HLS Streaming When Efficient.
You can join the TestFlight beta from an iPhone at https://getchannels.com/beta/ or you can email [email protected] with the email address you would like us to use to join the beta.
Eric,
Downloaded the beta client onto my non-4K Apple TV. Was dropping frames in the same way as the release client. I enabled the HLS when efficient option you mentioned. The client logs completely changed, and don’t show a counter of frame drops anymore. However, just watching the screen closely I could tell that it was still dropping frames at about the same rate as before, so that option didn’t seem to make a difference, at least for the frame drop issue.
Thanks for trying it out. I was suspecting this option would have more of an impact on @Danny0239's situation than yours, but it's always good to rule things out.
Since this is windows server with ATV4, have any of the users tried the auto tuning fix.? This has worked for me on multiple Chdvr servers and hasn’t impacted other uses or gameplay.
I really don’t think you’ll have any issues disabling Windows network autotune.
disabling Windows would surely work also.
So since ive been gone the following has happened:
New Network switch installed
Channels server wiped and reinstalled
New Network cables installed
Apple TV Factory reset and Channels app installed
Still having this infuriating issue.
Also have noticed that there is still two Channels apps on the App Store. Please can someone advise which is the correct one to use. Channels DVR or Channels - Live TV.
The apps are the same. It doesn't matter which one you use.
Can you try moving the DVR to bare-metal, or maybe to a Linux VM instead of Windows?
Which Linux Distro do you recommend and ill move it to that?
Whatever is simplest for you should be fine. I like Ubuntu server.
If you have the Channels DVR subscription, then you use the Channels DVR app.
You don't have to, but it'll save you a buck or two. If you don't have a DVR subscription you must use the "Live TV" version, for which you must pay separately. The "Live TV" version works both stand-alone and with the DVR.
Installed on Centos 7, moved data accross. Will test and let you know if its any different.
Right, Been testing this for nearly two weeks and am no longer having playback issues on the Apple TV. So the issue looks to lie in the way the Windows App works, or something else in windows causing the issue.
1 Like
So you changed from a Windows Server to a Linux server and now no issues? I have the same skips you had on your AppleTV but ONLY with Live TVE streaming.
Yeah, switched from windows to Linux and having no issues now. Mine was with recorded programmes however so not sure if it will fix your issue.
1 Like
For what it’s worth, I had to change my audio settings on my ATV4 to stereo only for my stuttering issue to stop.
I am getting affected by this issue. I have multiple Apple TV 4Ks and it happens on all of them when watching a recording (reproduced on OTA and TVE).
Before anyone assumes network related issue, all connections are hardwired ethernet. As a test, I play the same recording simultaneously on Apple TV and an NVidia Shield. The issue happened on my Apple TV but was playing fine on the Shield.
@tmm1 @eric Logs have been submitted as 92d06d8e-a300-4d1c-b15c-2114a247b73c