I have stuttering on TVE channels. I have an appletv4k and my channels dvr server is a quad core server with ssds so its not an bottleneck issue.
A good test is to tune to a news channel with a ticker like cnbc or something. Sometimes it will be Ok but after I watch a program or two and then tune to a news ticker station, it will stutter.
At least on the Apple TV you can enable “show stats” while viewing the recording and get lots of detailed info like buffer length (and transfer speed), as well as frame drops. Might help you narrow it down.
1 Like
Really? Really wish that could be a thing on Channels Android TV users. I asked about that ages ago in feature request. (Emby has that feature since forever on all platforms)
Which Audio & Video Drivers are you using on the ATV4K? I get stuttering video like you describe (also without any audio) when I use either of the Experimental A/V drivers and switch to a new channel via the Quick Guide. [edit: The stuttering I see with Experimental Drivers is when viewing live TVE channels: I have not tried with recordings, so it may not be what is happening in your case].
But when I use the Default A/V drivers, I do not get any stuttering after switching channels via the Quick Guide. (I am also using a RPi 4 USB BOOT Channels DVR, updated to the latest Beta.)
I'm using the default A/V drivers, have never tried the experimental, perhaps I should? Again, my only stuttering issue is when watching TVE recordings, nowhere else.
I am seeing the exact same stuttering on my TVE recordings. I am using Android and my server is a M1 Apple Mac Mini. I tried updating the software to 2021.02.27.2215 and that did not help.
I’m not using a Raspberry Pi, but am having the same stutter issue with TVE recordings.
I'm really hoping this is on the Devs 'bug' plate as it's really annoying. The recordings play perfectly over VLC but stutter when played on Channels. I thought it was just a Pi issue but it appears to be more widestpread.
As I understand it, this issue varies depending upon your client hardware device. Better devices (Apple TV, Nvidia Shield) don't have this problem, because their hardware video decoders are better than poorly maintained/implemented hardware decoders found in many Android-based devices.
In other words:
- Streaming providers (especially various TV networks) are not very good at ensuring their streams are normalized and consistent
- You get what you pay for
My current setup is Pi4 with WD USB3 hard drive feeding hardwire over network to Apple TV4K. I previously used my Synology 218+ NAS to my ATV4K. I tested going back to that to rule out/in the Pi4 at the culprit, no difference. Hardware is not my problem.
OTA recordings playback perfectly
TVE recordings playback with stutter
TVE live streams play perfectly
The issue is with how the TVE recordings are either recorded or played back via Channels.
I have a Ds 218+ and an Apple TV 4K and I do not have this problem, so it’s not a global thing. Can you narrow the scope of the problem? Does it happen on all TVE recordings, or just from certain channels? Does it seem like frames are being dropped? If so you can use the “show stats” option to confirm (or rule out). You can also use the stats to confirm the current buffer size and make sure you’re not having bandwidth issues.
It happens on multiple TVE channels but the two main ones are USA and AMC. My stats from ATV4K to server are attached and look pretty good. The big question is:
Why would playback of OTA recordings be perfect while TVE recording stutter?
Remember, watching live or OTA streams are perfect as are playing back the recordings on VLC.
Did you use the stats function to see if it shows dropped frames?
Three screenshots attached. One is TVE recorded show playback, one is OTA recorded show playback, one is live TV playback.
No dropped frames on any of them. The TVE recording is the only one that stutters.
Thanks for your help BTW, I’d love to find a solution. I’ve tried the experimental drivers with no change. Tuner sharing is off.
This has nothing to do with it. All TVE recordings are handled through the DVR server. Tuner Sharing only applies to HDHomeRun tuners on your local network. Everything else is handled by the DVR server.
I've been working with Aman concerning the stutter on TVE recordings with ATV. I think he is waiting for tvos 14.5 to come out becuase it supports 29.97 and 59.94 fps. Mine does seem to stutter much more than the micro frame skip every ~40seconds with playing at 30 or 60fps but Aman said that any coding changes for this would have to be redone for 14.5. Since the release is very soon he would revisit then.
Now I also have an nvidia shield tube and when I play the same TVE recording on the shield there I no stutter. It's as smooth as butter. I use the beta feature on the shield to match the frame rate and then the microstutter disappears as well.
1 Like
I had read about V14.5 also having this capability so I decided to try out the 14.5 beta. It’s very close to release so I felt comfortable trying. The above screen shots were made with the 14.5 beta. The FPS on the TVE shows 29.97 for both specified and estimated vs. 29.97 & 59.94 on the two others. Super happy to know that Aman will be looking into this. Thanks for your update.
1 Like
I just sent a note to Aman about this.
My tve recording I tried just now with the beta was great. Last night it was horrible (pre beta). Then I tried another and it is a bad as it ever was. But.... The frame rate is not detected so maybe we are on to something.
1 Like
Interesting. We watch that exact same show from a TVE source on an Apple TV 4K, so our use case should be identical. The only difference I see is that we’re using the default video and audio drivers. Does setting those back to defaults fix the problem?
Of course that doesn’t explain why the frame rate isn’t detected by the server...
I have been encountering some minor stuttering while playing back on my Apple TV4K 14.5. Just started recently, possibly with the 14.5 update.
I was reading this thread and had just tried rebooting my ATV and found that solved the problem. Definitely not my first guess, as it wasn’t consistent on all recordings, but it worked.
2 Likes