Do you have jumbo frames enabled? If yes, try disabling them. Also, flow control should match on switch ports and adapters. I'm more concerned about jumbo frames.
What is the storage for each server?
2 Likes
The original server:
Main Storage (3.6TB HDD - sda)
Operating System (232.8GB RAID0 - sdb & sdc)
Fast Storage (1.8TB NVMe SSD - nvme0n1)
- Stores /var (logs, databases, temporary files, etc.)
The mini PC (current)
-
Primary Drive (SATA SSD): 465.8GB (RAID Member)
- Partition 1: 1GB (vfat)
- Partition 2: 464.7GB (Linux RAID)
-
Secondary Drive (NVMe SSD): 476.9GB
- Partition 1: 1GB (vfat, mounted at /boot/efi)
- Partition 2: 475.9GB (Linux RAID)
- RAID Setup: md0 (ext4) spanning both drives
So a quick note - I only started my home lab journey a few years ago and it has been evolving ever since. Back when I cobbled together the original Plex/Channels box I didn't have a clear idea of how I wanted everything setup and was still (and still am) learning. I am currently in the process of streamlining everything which is what led me to finally try to track down what is going with Channels/HDHR.
So I just took a look at the USW 24 settings and see that it is using the Global Switch Settings - so Jumbo Frames was on. I have it off now. Flow control is also disabled, although I wonder if that might the next logical setting to try.
Did you have Jumbo Frames enabled on the server interface? If yes, turn it off there as well. Jumbo Frames can save CPU cycles, particularly for old NICs that do not have TCP offload. With modern NICs, the CPU savings is tiny. It's possibly that the throughput of a 10-Gb link might be a tiny bit smaller. Having all hosts including your Apple TV devices have the same frame size will avoid problems that some TCP stacks have when frame sizes don't match.
I'm going over common issues, the only way to find out if they are affecting you is to test as we are.
I'm retired from a long IT career. I've done a lot of different types of software development including Systems Engineering. This included software for the early networks and later I moved to Network Engineering and Management.
My concern with Jumbo Frames is that not all TCP stacks are created equal. While there are what appear to be very solid standards, it's amazing how two engineers can read the same standard and interoperate it slightly differently.
I don't think the issue is flow control as mish match results in overruns and/or drops which usually recover fast enough not to affect video. Frame size mismatch can have very strange symptoms and you have strange symptoms.
Again, I really appreciate the time and expertise you've shared in helping troubleshoot this issue.
I checked the MTU settings on the Mini PC, and it's correctly set to 1500, so we can rule out jumbo frames on that device. For now, I’m focusing solely on the Mini PC until I can track down the root cause.
A few promising observations:
- Before making the network changes, I would almost always experience a buffering pause within the first three minutes of starting a stream on the Apple TV.
- After that initial pause, buffering would occur sporadically—sometimes just once, other times multiple times over an hour or two.
- However, after making the network changes, I did not experience that initial buffering pause on re-testing.
The pessimist in me wants to chalk it up to coincidence, but I'll continue testing to see if the improvement holds.
If I do end up getting this sorted, maybe next you can help me get my AP radios correctly tuned so the UDM stops barking about airtime and overlapping channels 
(just kidding).
You don't have to wait for the network adapter to use the FireTV as you have WiFi. As long as there is a half decent signal you should be able to stream video as it doesn't take much bandwidth. Most of my channels devices are WiFi and I have no issues. I'm using Google TV devices.
I see in your latest diagnostics t hat you have Original Quality Delivery set to Stream. If you set it back to Direct now do you still have issues?
Hey Eric - Yes, I have always had it on original. I didn't mean to send the diagnostic - that just happened to be when I was testing to see if stream made a difference.
I just had an episode of 2 buffering pauses around 00:11:00 UTC (8:10pm EST). I submitted the diagnostic. If you have a second, can you take a look? I was also using the http logging on the device so I will take a look and see if I can see anything of note.
Here is a recap of the logs on my end.
- 20:09:51 – tuned into CBS (channel 502).
-
20:10:21 – ~30 seconds in, buffering:
Audio device underrun detected.Enter buffering (buffer went from 100% -> 0%)
-
20:10:43 – Another buffering event:
- Also an underrun → buffering lasted ~1.5 seconds.
- Cache dropped again from 100% → 0%.
Otherwise everything else seemed perfectly stable:
- Signal strength, quality, symbol: 100%
- Stream rate was good: ~10-11 Mb/sec
- Playback reported zero frames dropped
- Cache was doing well before both underruns
Does Settings > Playback > Advanced > Audio Driver: Legacy make any difference
That was going to be my next test. I am going to try that and will keep and eye on the logs. Getting closer to nailing this down. Thanks for all the help!
1 Like
This! Everything runs much better when I use legacy. Default audio causes stuttering audio and requires pausing playback or changing channels to stop it.
I wanted to confirm that even with "Use Legacy Audio Driver" turned ON, a full Apple TV reboot, and stereo output selected (with Surround OFF), Channels is still using the default audiounit driver, not the legacy one.
From the logs:
[ao] v: Trying audio driver 'avplayer'
[ao] v: Trying audio driver 'audiounit'
...
[cplayer] info: AO: [audiounit] 48000Hz stereo 2ch floatp
This shows that while avplayer is attempted, the system ends up selecting audiounit. I’ve confirmed this behavior across multiple ATV setups. Just looking for guidance on why the legacy driver isn’t sticking or being used even with the setting enabled and everything rebooted clean.
Thanks!
Noticed a discrepancy I wanted to highlight: the log shows [ao/audiounit] being used with passthrough enabled, which I believe is the newer audio backend. However, the “Show Stats” overlay in the app still reports “Legacy” under Audio Driver. Not sure if that’s just a labeling issue in the UI or if the client is falling back to legacy but not logging it clearly — figured it was worth flagging in case it helps track down the underruns.
Also, I am trying to get up to speed on all of this as quickly as I can, so I apologize if I am misunderstanding what the logs are actually saying here.
All that said, it does seem that the issue persists with legacy mode enabled.
2025-03-21 09:33:15.082 [u=204.7MB f=1893.3MB] [7.75s] [cplayer] warn: Audio device underrun detected.
2025-03-21 09:33:15.082 [u=205.0MB f=1893.0MB] [7.75s] [cplayer] v: restarting audio after underrun
UPDATE: Here is another more severe one with Legacy enabled
2025-03-21 11:23:21.169 [u=521.0MB f=1577.0MB] [6613.84s] [cplayer] warn: Audio device underrun detected.
2025-03-21 11:23:21.169 [u=521.0MB f=1577.0MB] [6613.84s] [cplayer] v: Enter buffering (buffer went from 100% -> 0%) [0.000000s].
2025-03-21 11:23:21.169 [u=521.0MB f=1577.0MB] [6613.84s] [vo/avfoundation] v: Frame duration changed: 33365 -> 50044
2025-03-21 11:23:21.179 [u=521.0MB f=1577.0MB] [6613.85s] [cplayer] v: Still buffering (buffer went from 63% -> 0%) [0.000000s].
2025-03-21 11:23:21.249 [u=521.3MB f=1576.6MB] [6613.92s] [cplayer] v: Still buffering (buffer went from 0% -> 63%) [0.160000s].
2025-03-21 11:23:21.251 [u=520.1MB f=1577.9MB] [6613.92s] [cplayer] v: End buffering (waited 2.715194 secs) [0.256000s].
2025-03-21 11:23:21.251 [u=520.2MB f=1577.8MB] [6613.92s] [cplayer] v: restarting audio after underrun
No packet loss, symbol errors, or low bitrate. Network appears stable.
FURTHER TESTING:
Apple TV vs Fire TV - Audio Cache & Format Comparison (Channels DVR)
Devices Tested:
- Apple TV 4K (2017, Model A1842)
- Apple TV 4K (2021, Model A2169)
- Fire TV 4K Max (latest gen)
Apple TV (Wired): (Tested on wi-fi as well. Only differece is lower buffer cache numbers with audio often pinned at 0.0s)
-
Audio Format:
ac3 (ATSC A/52A (AC-3)) -
Total Cache (Show Stats):
- Video: ~0.5–0.7 seconds
- Audio: ~0.1–0.2 seconds (frequently drops to 0.0)
-
Behavior:
- Frequent
audio device underrunerrors in logs - Playback buffers randomly, often after 10+ minutes
- Happens on both wired and Wi-Fi
- Frequent
Fire TV 4K Max (Wired):
-
Audio Format:
raw ac3 (raw audio passthrough decoder) -
Total Cache (Show Stats):
- Video: ~1.7–1.9 seconds
- Audio: ~0.6–0.8 seconds
-
Behavior:
- Smooth playback
- No underrun errors
I have also tested by pausing liveTV for 5-10 seconds and seeing what happens. The under runs still occur but there is no buffering pause.
Thanks again for the continued support and responses so far.
I’ve now run Xcode console logging alongside live playback and found no corresponding audio-related system messages when underruns occur. Specifically, I monitored the logs for the following:
underrun
audiounit
AVAudioSession
deactivateAudioSession
corespeechd
CSAudioProvider
interruption
StreamPrepared
At this point, I feel like I’ve exhausted every angle I can test on my end — including hardware variations, network analysis, driver settings, and logging — and I can’t move forward without more guidance from the team. I know the issue is minor but I would love to see it through this point.
I was also thinking about possible solutions after confirming the underruns don't cause buffering when I delay the live feed by just a few seconds:
- User-defined playback delay (A global setting to force a 3–10s buffer before live playback starts)
- Adaptive underrun handling (Functionality that will auto-float playback back a few seconds if an underrun is detected so that the stream won't buffer every time there is an underrun)
I'm happy to do whatever to try and find the cause and/or solution for this issue and am just trying to find a reliable path forward at this point.
Thanks!
I know this sounds odd, but by any chance do you have IPv6 turned on? Whenever I use IPv6 on my network I have random issues with Channels. For that and other reasons, I no longer use IPv6. I still get the random OTA picture pause/menu bar pop-up. I think it's because there is almost no buffer for OTA. On TVE I see about 15 seconds of buffer.
Thanks for the reply! Unfortunately, I already have IPv6 disabled in my UDM Pro settings and have for a while. I agree that the issue seems to be the lack of any real buffer when watching Live TV through the HDHR Prime. In most cases, the underruns recover really quickly—usually within half a second—but the buffering pause is what makes it noticeable. The simplest workaround I’ve found is to pause Live TV for 3 seconds to give the buffer a little room, which got me thinking about whether a setting or feature could help handle that kind of thing automatically.