No it's 1080p. But GOP 10 seems to look good and so far it seems to be working with software decoding on the Shield. Hardware decoding stuttered for sure but software kept up with the little bit I could test on my lunch break!
Check the manual for your specific device, but I think the GOP setting on the uraycoder devices might be configured in frames and not seconds. So if you are running at 60fps you might actually want a GOP setting of 120 frames (two seconds).
Interesting. I wonder why going from a GOP of 60 to 5 fixed my problem with stuttering ADBTuner streams in CDVR Multiview then?
It wasn't happening with streams from a LinkPi, only from a URayCoder -- and most settings other than GOP were very similar.
1 Like
I initially started with LinkPi defaults, which included CBR. I'm pretty sure that I eventually chose VBR over CBR because this guy said that it is what he was using: 
The stuttering was evident when only a single tuner was being used for recording. I suspect that because I am not allowing the devices to sleep, they are all constantly contributing to the total load on the encoder.
I could very much be incorrect. You know these devices, they don't always act as expected.
And you could be exactly right. 
I was surprised when setting it to the minimum was the fix -- but was mostly just glad there was a fix. Ultimately, when I get a newer gen ATV, I'll experiment with it more.
Going to 120 looks SO much better! I think in my case I have to dial the bitrate in, just keep reducing until the stuttering stops. Thank you!
1 Like
Well my curiosity got to me so I wanted to verify the LinkPi output:
There might be an easier way to do this, but presuming one has ffmpeg and mediainfo installed you can do the following to confirm the GOP length on the output stream. This will download 30 seconds of video and use mediainfo to analyze it.
ffmpeg -i "http://x.x.x.x/path-to-stream" -vcodec copy -acodec copy -t 30 /tmp/out.ts
mediainfo /tmp/out.ts | grep GOP
Format settings, GOP : M=1, N=120
This is what I get with the LinkPi configured with a GOP of 2 seconds. The number of frames is 120 which is correct for 60 fps video.
Hmm.. maybe ADBTuner could have some video stats in the streaming endpoint preview window.
2 Likes
Well, I guess I could flag this old post. I don’t remember when but did change to CBR at some point, and it’s been that way for a while. Likely during my jump between AH4C and ADBT tests with Onn and Ospreys. Sorry about that.
Still tinkering. I figured out in the stats on my device it's output frames being dropped!
I disabled all the extra protocols so only the TS stream is active. This "may" help reduce load/memory use on the encoder.
1 Like
I don't think it's the encoder because both of my encoders (one Uray the other is from the same ODM but a no name, similar firmware though) do the same thing. I think it may have something to do with TS Once Pack (increasing that) and setting a low VBR target like 6000. It's a lot of experimenting.
1 Like
Not a problem at all. I appreciate any suggestions I may receive. This whole streaming/CDVR setup is to hit a constantly moving target. What seemed to be the best settings at one time may evolve to something more refined as time passes. I'm still not completely committed to my current settings. I'll try switching back to CBR...
I never managed to get my ONN boxes to run DirecTV very well with ADBT. That is why I have the Roku sticks. They are working out perfectly with DTV using Roku Tuner Bridge. For me, three is the minimum tuner number for either setup. It allows at least two simultaneous recordings and channel changes with pre/post recording buffer overlap. That's how I ended up with two setups, three tuners each.
Switching from Direct to Stream fixed my dropped frames issue on my phone and Shield, unfortunately for some reason the Shield would then lock up on DVR recordings. I imagine that has to do with being 7 years old, so I switched to a Google TV Streamer and all is well. I guess I needed it to remux 
.
So my issue was not my encoders. It ended up being both of the Shields. I factory reset them both and everything is normal with Direct Mode. No more weird buffering, just normal behavior.
I guess something system level was corrupted!! Thank you all for all of your help. 
1 Like
Yeah...sometimes a clean slate solves everything.
It seemed to even solve all of the random buffering and also the lockups I was having when I was using stream mode.
I've actually been able to switch back to direct mode and just drop my bitrate to 8000kbps and it seems to be stable.
edited: typo
I pushed an update this morning (Beta: 2.0-Beta-20251114-1, Development: 20251114-1) with some proxy optimizations that might help eliminate occasional stutters during playback on some devices.
@mackid1993 this might have had something to do with what you were seeing. Please update when you can and let me know if you run into this again. Thanks!
3 Likes
I'm testing right now, there's definitely way less of a delay between what I see in the preview on my encoder and what's actually coming up on my screen.
I'm actually testing from a remote location now on my phone, so that should really stress the network, and that was definitely stuttering the other day. This is going over tailscale, direct stream, over the internet.
So far it seems good!!
I have plenty of time to watch TV this weekend, so I'm going to see if it buffers for sure!!