Frameskipping in the most 1080p files


#143

I think I’ve seen the same behavior (buffering drop to cca 10%) when the movie is started from the network (wifi and 1gbps LAN) and from the usb. From all three sources. I’ll check again to make sure that the result is the same and inform you. The drop starts after 20-30 minutes of the movie, and I see no reason for that.


#144

Can you take a screenshot of the OSD when it happens? Pressing the button with three lines (context menu) and then OK should get the vq: and aq: numbers.


#145

So, the March version clearly shows the same behaviour. Skipping at different points of the video, no matter whether it’s played from USB, SMB or the internal storage… Also, a clean install of OSMC didn’t bring any change.


#146

I looked at @Chillbo’s recording. I can see some stutters but that may be related to the recording itself.

@MikeDelta, thanks for the recording. The post on 4K skips seems to indicate for sure that the issue the buffer running too low.

For your recording I can see that VQ: stays in the 70% area, which suggests that isn’t the issue here. If I starve the buffer intentionally I can get some skips, but pressing Pause then Play resolves this for me.

@Chillbo sent me some new logs and I can see that there is no sign of framerate automation kicking in, which controls fractional modesetting. For example, when I play 23.976 content with Adjust Refresh Rate, I get:

[148573.152178] tv_vout: framerate_automation_process[1111] fps_playing_flag = 0
[153462.362751] tv_vout: vout [framerate_automation_process] duration = 3844

I suspect a direct connection to the TV or even a different receiver, and you’ll get the same kernel messages and won’t see any skips.

Framerate automation won’t kick in if the kernel doesn’t think that your device supports it. So this explains skips. I think the red herring was that they ‘appear’ a while in to a movie. If this is the issue, then they should be right there from the start.

In the next series of video improvements, we will expose the refresh rates via sysfs so that Kodi itself has control over fractional modesetting. This will remove this problem; if that is the problem, which it certainly is beginning to look like.

I was hoping to get that done today but have been trying to catch up on the forum and seeing what can be done to remedy this.

Now I will try and produce a kernel which:

  • forces fractional modesetting, even when the AVR claims not to support it
  • dumps further logs so I can see what’s going on.

In the interim, please update your devices to the latest version so we can get on the same page.

Cheers

Sam


#147

Thanks a lot for the reply…
I understand correctly that the Vero won’t send proper 23.976fps to the TV/AVR because of some false advertising by the TV and/or AVR? Still very strange why all other devices I use, like a blu-ray player which mostly plays 23.976fps content, don’t show any stutter. Do those devices ignore the advertising already? Any idea on that?

So, that behaviour itself wouldn’t really point to false advertising?

I’m on the newest version and waiting for anything new…


#148

No – if we weren’t pushing out 23.976 I’d expect you to see that constant judder once every 42s. The video improvements will probably fix this, but it’d be nice to figure out the exact issue before I make a lot of changes

This is why it’s a bit confusing. Some devices override what the TV reports. We have had to do that before

I’ll let you know when the new kernel is ready

Sam


#149

Confusing it is indeed… 23.976fps can’t be forced on my Vero by terminal command, no 42 seconds judder visible (I also tested the Kodi test file which shows moving bars - the problem should be very much visible there), but still skips?? :confounded: I don’t get all this…


#150

One other thing I can think of is that your TV is somehow compensating for the skips you would normally see every 40sec or so.


#151

All picture enhancement or any framerate smoothening is disabled. Wouldn’t know how else the TV could compensate the issue…


#152

These skips happens at sometime while playing almost any mkv 1080P movie I’ve tried. Pause & Play will fix it, but it’s pretty annoying.


#153

My english isn´t very good, so please forgive me that i´m not understood all of them you wrote here… what i can say for information is that press Pause then Play doesn´t resolve the frame skipping problem, it continues after… and i´m understand right that in my case both Vero have not a buffer underrun problem or so? Does this mean that my problem can´t solve with a new kernel and the video improvements you wrote?


#154

@sam_nazarko replied to my logs and recordings… and my problems are not solved by pressing play/pause either. His hope is that my (and maybe also your) problems will be solved with the new kernel!


#155

Ok, thanks - hope it too… and that it will not be a neverending story…


#156

Pause and Play fixes the issue for @acidduck and his 4K clips because we have a buffer issue there. It’s already being worked on to improve performance for higher bitrate content.

It doesn’t fix it for you guys because something else is at play. For both your recordings the buffer is fine. They are two different issues and thankfully in two different threads :slight_smile:


#157

We will solve it. I appreciate the patience

Sam


#158

So, the we might be able to expect a test kernel tomorrow? I don’t want to hurry you, just would like to know :wink:


#159

I have the needed patience, think the Vero 4k is the player i´m waiting for - and when the himedia q10 have a problem it takes weeks to fix it, for me an absolute nogo, that´s the main reason i´ve searching for an alternative!


#160

A little later this evening

After that, I’ll work on the new video scheme. We are moving to that eventually so it makes sense to target that and get your system working with this new approach


#161

Awesome, thx!


#162

Here, please try this:

wget "https://www.dropbox.com/s/wazpfxegwf71qsa/vero364-image-3.14.29-21-osmc.deb?dl=1" -O kernel.deb
sudo dpkg -i kernel.deb
reboot

and upload logs

Quite late here, so will follow up on things tomorrow morning.

Sam