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

Channels Apple TV
#63

Not for nothing, but a few HDHR issues seem to have popped up since their newest firmwares came out. Timing seems suspicious.

The UPnP one in particular.

**HDHomeRun Firmware** (20250117beta1):
* ATSC3: Fix problem handling 4K test broadcast from Canada.
* ATSC3: Fix problem where incorrect parental rating could be applied.
* TECH5/DEV: Fix problem with ATSC3 "forward" output format where power-save mode could activate stopping operation.
* TECH5: Auto-restart demodulation when needed on older ATSC1-only models.
* HDD models: Improve handling of a failing hard drive.
* UPnP: Only announce services using the primary IPv4 and primary IPv6 address.
* MDNS: Improvements to MDNS handling.

**HDHomeRun Firmware** 20250130beta1
* Add signal strength/quality to the channel scan results
Why didn't this recording go down the channel list? (OTA signal failed)
#64

If you have concerns that this has affected you post in the HDHR Forum or file trouble ticket ... I have 2 Primes and 3 4 tuner devices and do not have this problem. Silicondust if you report it will look at your units remotely.

#65

Thanks, I’ll definitely reach out to them as well. The reason I’m focusing here is because the issue only occurs when watching through the Channels app on my Apple TVs. If I use Plex or the HDHomeRun app on the same Apple TVs, the issue doesn’t happen. It also doesn’t occur when using the Channels app on my Fire Stick.

Just to clarify—are you using your HDHR Primes specifically with Channels on Apple TV?

#66

Thanks for the reply, and that is good to know. I am still on stable release 20230713 but might be worth giving the beta release a try and seeing if I get any differing behaviors.

#67

I am on the beta, have been since it came out. No difference in the issue

#68

This is exactly what I’ve been doing as well. At this point, a setting that introduces a preset delay whenever a new channel starts playing seems like it would be a great solution. The real annoyance for me right now is that if I want to rewind and rewatch a play, I then have to go back to live, pause again, and then hit play. Not the end of the world, but a delay setting would be a really nice quality-of-life improvement.

I also started looking into other, more involved ideas. Since this always seems to happen when the audio buffer hits 0 during an underrun, I wondered if it might be possible to adaptively slow down the stream slightly when an underrun is detected—then speed it back up gradually once the buffer recovers. Kind of like an on-the-fly delay that only kicks in when needed.

Not sure how practical that is, and honestly, the static delay option seems like the most straightforward and sensible approach.

#69

Does not even need to be much of a buffer. I am hitting pause play for less than a second and that gives just enough audio buffer to keep it going. A zero audio buffer just does not work well. Even my Dante audio gear has a few milliseconds of buffer.

#70

That’s good to know. I’ve been more conservative—usually pausing for about 3 full seconds, which gives me around 10 seconds of audio buffer.

#71

I use a Harmony remote and I bet I could write a macro that would do this for me. It's a really sketch way to fix this but its better than the dozen or so pauses I had last night on every channel I was trying to watch while we were under a tornado warning.

#72

No only use FireTV Devices.

#73

Been running Channels with just .4 seconds of audio buffer and I have no pauses or menu pop ups. No audio underrun errors.

That's point four seconds, not 4 seconds!!!

#74

This part of the code is very finicky, and every new tvOS release seems to affect it some way.

Thank you guys for all your debugging so far. We've made some changes based on your observations in the latest prerelease. Let us know if it helps.

#75

If I don’t use tuner sharing then how does an update to the DVR software help? it seems that the fix needs to be made in the tvOS app not the DVR software running on my Mac?

#76

Oops my bad. The beta is uploading now.

1 Like
#77

Interesting, I see now that as soon as I change channels there is 1 buffering pause listed in the stats. I don't see the pause on screen, but the stats say it happened. Novel way to attack the issue, create a pause as it tunes.

#78

Thanks for all the help on this. Love channels as well as the awesome community you guys have. I'll try out the beta today.

#79

What I found during testing is that by manually introducing a buffer — I was being conservative with around 10 seconds of audio — I still saw underruns in the logs, but because the cache was so large, it never came close to emptying. As a result, there were no visible issues or buffering pauses shown in the stats.

I also noticed that I almost always get an initial buffering pause within a few seconds of starting a new channel, which lines up with an underrun. That said, it doesn’t happen consistently every time.

Gonna try the beta an monitor the logs today.

1 Like
#80

I have not had a single buffer pause all day since updating to the beta on my ATV.

1 Like
#81

Just curious - were you also seeing the audio underruns as the cause of the buffering pauses when they were happening? Sorry if you already confirmed this and I missed it.

#82

Channels tvOS Beta Testing Summary – April 2, 2025

Build: Latest tvOS beta as of 4/2/2025
Logs Submitted: Yes

Behavior Observed:

Still seeing audio underruns in the beta, with matching buffering pauses visible in the logs. The buffer reaches 0.00s audio (video buffer is typically 0.20–0.30s), which triggers the underrun and a brief pause.

In some cases, the underrun triggers a visible pause and UI bar pop-up. In others, playback continues uninterrupted, suggesting a brief buffer recovery before visual disruption.

Example Log Block from a More Severe Underrun:

2025-04-02 08:05:38.865 mpvstats: AV: 755.838 A-V: 0.000007 Dropped: 4 Container FPS: 29.97 Estimated FPS: 59.94 Cache: 0.30s  video + 0.00s audio
2025-04-02 08:05:38.865 Updating playState from LTVideoPlayerPlayStatePlaying to LTVideoPlayerPlayStateBuffering
2025-04-02 08:05:38.865 [cplayer] warn: Audio device underrun detected.
2025-04-02 08:05:38.865 [cplayer] Enter buffering (buffer went from 100% -> 0%)
2025-04-02 08:05:38.900 [cplayer] Still buffering (buffer went from 64% -> 0%)
2025-04-02 08:05:39.020 [cplayer] End buffering (waited 0.476569 secs)
2025-04-02 08:05:39.020 [cplayer] restarting audio after underrun

Network Investigation Ongoing:

  • Replaced coax from ONT to HDHR Prime
  • Swapped switches and tested playback both wired and via Wi-Fi
  • Consistently seeing solid signal: 100% strength, 100% quality, 0 symbol errors, 0 dropped packets
  • Planning to replace the CAT6 between the ONT and switch next
  • iPerf tests look good but I am going to run for a longer duration between the server and ATV today

I'll continue to investigate possible network causes, but if there are any network-level variables or suggestions you'd like me to explore further, I’m happy to dig in.

Thanks again for the continued support!