Ok great.
Latest beta is having constant pauses especially after changing sources.
Did a bunch of comparisons today between the beta and the release version. Used the experimental deinterlace and video drivers along with default audio driver.
On the beta or the release version TVE channels tune properly and don’t stutter or pause.
On the beta tuning ATSC 1 channels always results in several audio dropouts in a row after tuning. The release may drop once. Video remains stable on both and never pauses.
On ATSC 3 the beta has issues. The video freezes after tuning while the audio plays. Then the video speeds up trying to catch the audio which results in a couple of speed up-slow downs and audio hits until they get in sync. No issues on the release other than the long delay to get the stream going which is par for course on h.265 and not unique to Channels.
1 Like
Thanks for that summary. The issues with ATSC3 channels should be fixed, and the default driver should also behave the same between beta and store builds now.
1 Like
Ok, give me a little bit to download and run some tests. Thx.
1 Like
Everything seems stable now on all sources, 1.0, 3.0 and TVE. I tried default and experimental audio drivers. No more pauses, timeline popping up or video ramping speed.
Two things I have noticed across all versions. Sometimes certain ATSC 1 sources have a slight dither effect in the audio. Could be source no real way to tell.
Also, and this could be my audio system, when I change sources the first few seconds after the video locks the audio will do 2-3 very brief dropouts within the first 10 seconds then stable from then on.
1 Like
My better half was trying to watch the Food Network TVE tonight and it was pausing constantly. Went back to the 5.10 release. Stable. So it may not be completely cured 
Log sent this morning.
12/1/21
I have been using the latest beta, seems stable on tve but I will monitor for a few days before I say that for sure. But one thing that never changes is when tuning my HDHR on any version, the first few seconds after changing a channel stutter and drops sound. I was reading in a Silicon Dust developer manual than this can happen when the buffer is not large enough as the frame rate of the client adjusts to the frame rate of broadcaster. The buffer can run out.
Is there any way to monitor the buffer to see if this is the cause? Or monitor anything about the stream in the first few seconds to identify the stutter?
I do see that the cache always says 0 seconds on HDHR feeds.
- III.Client requirements for live TV
The stream is delivered to the client in real time as it arrives from the broadcast source.
- The client will have a slightly different concept of how long one second is due to slight differences in the client clock timebase vs the broadcaster clock timebase. The client must adjust its concept of real time to match the incoming video stream. For example, if the client is displaying frames slightly faster than the incoming stream rate it will slowly empty the input jitter buffer. Alternatively if the client is displaying frames slightly slower than the incoming stream rate it will slowly fill up and overflow the input jitter buffer. For live TV the client must adjust its concept of real time by increasing or decreasing the frame rate slightly to match the rate at which data is arriving.
- The initial buffering of data by the client must be based on time, not size. The stream is sent in real time which means the amount of data received in one second will be lower on SD channels vs HD channels.
- There may be a delay between the HTTP request and data being returned. The initial buffering of data by the client must be based on time, starting from the first data arriving.
- The client input jitter buffer max-size must be larger than the worst case amount of data that can be sent in the initial buffering time. This allows for 1) detecting if the client is running slower than the stream rate (see above), and 2) if the client takes time to set up the video rendering components after detecting the stream content it must continue to buffer (not drop data) during this setup time.
I've never experienced this myself. Maybe you can make a video of it happening
So it never happens recordings.
And it never happens on TVE? That might make sense, since TVE buffers are much larger.
If you set your Home Streaming Quality to 8mbps instead of Original, it will change how the buffering occurs. Does it stop happening in that mode with live HDHR?
video sent to support email
I will test after I get off my Zoom call for work
Wow that's pretty bad. If you're able to also test and see if it happens with just the TV speakers, that would be a useful data point.
All 3 of my ATV units display the same issue. Ones hooked up direct to TV's with no sound system do the same thing. two units are 1st gen 4K TV and the video I sent you is from the 2nd gen 4K ATV
tried limiting to 8mb. It was worse. Constant buffering and a repeating flicker in the picture every second.
By the way I have tried running the server on three different computers and I get the same issues from all. Current server is a 2012 Mac mini i5.
Logs sent. 7afa0289-0a52-4a04-a60f-ab1a2ceca829
Very interesting. Did I ask you to try the official HDHR app already to compare?
nope, but give me a minute and I will download it and try.
Well I should have done that earlier, but I hate that app so much I forgot about it. Anyway the same issue on that app, so its not Channels. Must be something in the latest firmware they pushed to my HDHR. Was solid until a few weeks ago.
Sorry for the tail chasing
Pretty strange. Definitely reach out to them and see if they can shed any light. You'll want to enable the diagnostics checkbox on your HDHR's web UI