As @Chillbo already mentioned, that’s not an issue. Unfortunately, the thread sleep latency of the 4.9 kernel has increased and isn’t as stable as it was with the 3.14 kernel. That instability was causing frame skips when playing MVC clips. As a workaround I’ve changed the way how Kodi plays MVC files but that causes higher CPU usage and temperature. But everything’s still within all the limits.
2 Likes
I’m back from travelling now.
By the time you wake up, there should be an update available which restores those VC-1 improvements made earlier.
Thanks for checking and confirming this before release
Sam
I think there was an update overnight, but the Auto-Select deinterlacing option is still not doing what it was doing a week ago - it’s still late-August behaviour.
Maybe the change hasn’t reached me yet? What’s a quick way to check if I’m properly updated to the latest version?
I just applied an update and I’m not getting correct frame deinterlacing even with deinterlace set to off. However for general release this may be ok as there is no stutter, and hold back the new auto enhancements pending further testing?
It didn’t even occur to me to test that, but you’re right - it’s doing a field-deinterlace even with Deinterlacing set to Off. 
I didn’t have the impression that’s what Sam and Graham were planning to do…
A case could be made for (temporarily) keeping the behaviour of the Auto-Select option reverted (so it always uses a field-deinterlace and therefore doesn’t stutter). But I can’t see any good reason to prevent the “Off” option from working the way it used to - while that used to stutter with 50Hz output, it’s always been smooth (for me, anyway) with output set to 25Hz. Clearly that shouldn’t be the default option, because it messes up things like credits, but I can’t see the point in (effectively) removing the option entirely.
It’s not our call, of course. 
@sam_nazarko and @grahamh , what’s the official plan, here? (I mean, what’s the expected result for a test?)
The fix that has been tested by you which involves having three options (auto, off, interlacing) will be brought back. It’s just a momentary issue why the fix has gone missing. It should finally be on its way to the staging repository as we speak (from what I understood - do correct me, if wrong, @sam_nazarko). Before, it was still missing, so your latest tests didn’t show he expected results - the expected “auto” behaviour with some stutter every now and then.
The stutter is another issue introduced by Kodi’s whitelist logic. It might get addressed some day, but not imminently.
It will be sorted in a couple of hours.
It doesn’t seem like a whitelist logic problem. The problem is that the device apparently can’t correctly convert 1080p/25fps to 1080p/50Hz.
In the case where Deinterlacing is set to “Off”, allowing the device to switch automatically to 1080p/25Hz would be a useful workaround. But you couldn’t use that approach in “Auto-select” mode: in cases where the video is field-interlaced, the Auto option has to output 50 deinterlaced frames per second, not 25; and since the interlace method can switch at any time, the output has to be 50Hz at all times.
Noted.
If you have a TV that’s not limited to HDMI modes from the pre-HDMI 2.0 era: Most FHD TVs (like mine) do not accept 25fps at any resolution, but only 50fps. 
Well, sure: what you really need to do is to get the device to output 1080p/25fps at 1080p/50Hz without stuttering. That’s the only way to fix “Auto-select” mode, and the best way to fix “Off” mode. But as this is apparently not going to happen for quite some time, it might be worth considering partial work-arounds at some point.
Let’s focus on getting the ‘three option’ VC1 deinterlacing fix in place (and confirmed ) and the update out of the door first. Everything else can come then 
Everything now seems to be back to where it should be.
1 Like
just applied the latest update, some observations on my 1080/50i VC-1 test into my Panny OLED:
whitelist only 1080/25p and set deinterlacing to off: picture quality is really stunning, motion seems perfect. Never seen a picture from this source as good as this.
whitelist only 1080/25p and set deinterlacing to auto: playback switches between smooth segments and occasionally goes off the rails where I guess it switches to field-based deinterlacing when it shouldn’t. So auto is currently failing the 25p output test (for all I know that’s due to poor authoring, I would not know if this is fixable)
have no whitelist at all and set deinterlacing to auto: occasional stutter, picture is generally free of moire but occasionally there is tell-tale moire, this coincides with segments where auto fails on 25p output.
no whitelist and deinterlacing set to off: clean picture, but some stutter issues.
That’s definitely what that is. Auto-select with forced 25Hz output isn’t really a valid combination, IMO - when the video is field-interlace, the deinterlacer is producing 50 frames per second, but can only output 25, so it’s not surprising it goes a bit peculiar.
@grahamh will no doubt correct me if I’m wrong, but I think the video metadata is the only thing “Auto-select” has to go on - in which case it probably is poor authoring, and there probably isn’t anything that can be done.
At the risk of sounding like a stuck record, I’m not sure the stuttering problem is something you can ignore… It’s not an occasional stutter here and there - with Deinterlacing set to “Auto-select” (the default) a clip either plays perfectly smoothly, or it stutters continuously for the entire length of the clip. It seems to be more less random which it does - the same clip can play smoothly three times in a row and then stutter the fourth time. Pausing and restarting the video can sometimes flip it from stuttery to smooth (or vice versa). Very odd.
The other possible issue (which I’ve also mentioned before) is that on those BBC discs where they’ve inexplicably decided to convert to 60Hz, “Auto-select” gives sub-optimal behaviour, and they look much better if you set them to “Deinterlace” instead. (This is quite likely to be an authoring problem; but it seems to be a rather common authoring problem!).
Those two issues aside, it’s looking really good now. The improvement in the basic VC-1 decoding relative to the previous (non-test) release is particularly striking - everything is much clearer and more detailed, and it’s stopped doing that strange thing of looking as if it’s rendering at 6- or 7-bit accuracy instead of 8 and blowing out highlights. Big improvement.
It’s not a release blocker.
Did it stutter before the VC-1 changes were made?
Sam
It used to stutter only with Deinterlacing set to Off; it now stutters on both Off and Auto-select settings. Auto-select is the default, of course; so people who used not to see stutter (because they never changed the Deinterlacing setting) will now see it.
If it were up to me I would probably release the software in its current form and plan to address the stuttering issue for the next release after the current one.
Obviously it’s not up to me. 
But it would be nice not to postpone that one indefinitely.
I spent another hour or two trying out some ideas yesterday and can’t improve on what we’ve got. I propose we make the default ‘deinterlace’ as that seems to cause fewer problems than the other two options. Thank you both for all the testing.
2 Likes
it’s the d-day friends… we are ready to landing to stable brach ?
my pi2 it’s waiting
edit
my prerequisites question it’s:
i try to “df -h” by ssh on my pi2.
i have found about 2GB of free space on my SD will it be enough?
for absurd:
osmc@osmc:~$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 204M 0 204M 0% /dev
tmpfs 461M 6.1M 455M 2% /run
/dev/mmcblk0p2 7.0G 4.7G 2.0G 72% /
tmpfs 461M 0 461M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 461M 0 461M 0% /sys/fs/cgroup
/dev/mmcblk0p1 316M 76M 240M 25% /boot
tmpfs 93M 0 93M 0% /run/user/1000
osmc@osmc:~$