LiveTV Buffering Pauses due to 'audiounderrun' - HDHR Prime Source

Channels Apple TV
#35

Hey @tmm1 - So I did some more testing today. Just curious - with my old setup I had the channels data and storage directory on my TrueNAS core server, so it wasn't on the same server that channelsDVR was running on. This was an NFS share.

Today, I decided to install channels on a clean mini PC I had lying around and instead of mounting to TrueNAS, I made the channels data and store dir local on the mini PC. After a few hours of watching TV, everything was much smoother.

Is it possible or even a know issue that using a NFS share for the channels data directory could have led to the intermittent buffering and freezing? Thanks

#36

There are no known issues with using network storage but all additional components (network gear, storage layers, compute layers) add additional complexity that can introduce hard-to-diagnose performance issues.

We always suggest using the simplest possible setup not because it can’t work well on a complicated setup, but because the more complex your situation is, the harder it is to understand when it goes wrong.

#37

I've been using an SMB share for channels for years and use to have that share on TrueNAS Core and later TrueNAS Scale. Both worked great except for the fact that TrueNAS does not implement modern power saving which lead me to migrate to Unraid. I continue to get wonderful performance with Unraid. You did not say what your server was yet NFS may not have been the best choice. Another possibility is you had a network issue or a network card driver issue.

1 Like
#38

Thanks, Morris. I haven't been able to pinpoint any network-related cause for the issue. My original server was a repurposed gaming PC (9900K, GTX 1080, 64GB DDR4, etc.). I initially suspected a network card issue, but after testing multiple PCIe cards and even an SFP+ card, the problem persisted.

I've also been monitoring the logs on my switch, but I haven’t seen anything unusual there either.

Plex runs on the same server without any issues, though that may not be particularly telling. That said, I'll continue keeping an eye on performance with the mini PC running the N100 chip. I watched for an hour last night without any buffering, so I'm hopeful this setup will be more stable.

1 Like
#39

This suggests the old computer may have an issue. Did you move the hard drive from the old PC to the new one? Your old computer was way over powered for Channels DVR and Plex. Your N100 will save you a bunch of funds over time. I'm running both Channels DVR and Plex on the primary Windows 11 Pro install of my N100. I also have Hyper-V enabled and run some network management software on another Windows 11 Pro VM. Never any buffering, everything just works. I'm amazed what the little system can do. My storage is on a NAS yet that should make little difference for the load.

Hopefully your system stays stable. Time will tell

2 Likes
#40

Unfortunately the issue persists on the mini PC as well and I have continued to troubleshoot. Here is a recap of the situation:

Intermittent Buffering on LiveTV

Tuner Hardware:
HDHR Prime

Networking equiptment:

Unifi UDM Pro Network Controller
Unifi USW Pro 24 PoE Switch

Sever Hardware (both with the same behavior):

  1. 9900k cpu / 32gb ddr4 repurposed gaming pc. Runs Plex as well with no issues
  2. Trigkey Mini pc w/ n100 chip

Affected Clients:

AppleTV 4K 2017 (A1842) - connected directly to the 24 port swtich
AppleTV 4K 2021 (A2169) - connected to a 8 port unifi switch which is connected to the 24 port switch

Recap of issue:
While watching liveTV, the feed will momentarily pause. When checking the 'show stats' option in the appleTV menu, the number of buffering pauses will go up by 1 each time.
All devices are hardwired directly to 24 port network switch

Silicon Dust Testing:

  • Ran a packet loss test from the HDHR Prime to my Windows 11 PC for an hour with no packet loss reported. I have also watched liveTV directly on the AppleTV via the HDHomeRun app without any buffering pauses.
  • Checked signal strength in the HDHR webUI to confirm strength and quality are 100%

Channels troubleshooting/notes:

  • Behavior Occurs with both tuner sharing on and off
  • Adjusting match content does not resolve the issue
  • Behavior occurs through both direct and stream options
  • I have pulled up a live channel on my iPad while also watching on the AppleTV. There are no buffering/pauses on the iPad when the issue occurs on the AppleTV
  • Nothing in the Channels logs capturing the issue

Network troubleshooting:

  • Replace cables and change ports
  • Actively monitoring the unifi logs for any errors or signs of packet loss (none)
  • Tested connected between the network controller and AppleTVs

Next Steps:

  • I have an Amazon Fire Stick that I am going to test with. I am waiting on a ethernet adapter so I can test it wired. Curious to see if I get the same errors.
  • Submit diganostics from Apple TV next time the issues occurs

I am trying to be a diligent as possible in diagnosing the issues, but it is becoming increasingly frustrating to not be able to capture it in a way that gives me some idea of where the issue lies.

#41

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
#42

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.

#43

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.

#44

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 :laughing: (just kidding).

1 Like
#45

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.

#46

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?

#47

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.

#48

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
#49

Does Settings > Playback > Advanced > Audio Driver: Legacy make any difference

#50

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
#51

This! Everything runs much better when I use legacy. Default audio causes stuttering audio and requires pausing playback or changing channels to stop it.

#52

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!

#53

@eric

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 underrun errors in logs
    • Playback buffers randomly, often after 10+ minutes
    • Happens on both wired and Wi-Fi

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.

#54

@tmm1 @eric

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!

Audio choppy OTA HDHR