OSMC 18 - Refresh Rate Adjustment Behavior

Help and Support Vero 4K / Vero 4K +
1

I just applied the April update for OSMC that bumped the version to 18/Leia, and I noticed that it appears to have changed the rules for which refresh rates changes will trigger. I watch a reasonable amount of PAL content, and my television supports 2160p@25Hz, but doesn’t support 1080p@25Hz. In 17/Krypton, if I played a 1080p/25 file, Kodi would switch to 2160p/25 to match the refresh rate, even though it forced internal upscaling. In v18, it just leaves the system at 1080p/59.94Hz (my GUI defaults), instead of making an attempt to match the refresh rate.

Is there any hidden setting I could adjust to revert to the old behavior? I greatly preferred having stutter-free playback in exchange for slightly lower quality upscaling, and this new behavior feels like a major regression.

2

Well not hidden but I assume resolution whitelisting would serve your purpose.

3

I already tried fiddling with the resolution whitelisting section, but that doesn’t have any effect on this issue, unfortunately. Even if literally the only resolution I whitelist is 2160/25, Kodi refuses to switch to it for 1080/25 content. The only way I can force the content to play at 2160/25 is to manually set that as Kodi’s GUI resolution, which is obviously an undesirable workaround.

As far as I can tell, Kodi is just prioritizing matching resolution over matching refresh rate under the new ruleset, since switching on 1080/24 content (which is a resolution/refresh rate my television does support directly) still works perfectly.

4

A log should show the rationale behind choosing frame rates.

Sam

5

Got it. I’ll pull a log this evening and see what it shows. I assumed this was just an intentional upstream Kodi change, not a potential bug.

6

I think that is indeed what Kodi will do; but the log will let us see in more detail what’s going on.

Sam

7

As I understand it, and from some testing today, if you invoke the whitelist kodi will only switch to a resolution on that list if it is an exact match for the video, right down to the fractional frame rate.

8

I was wondering about the whitelist having an impact, but I also tested with no whitelisting at all (e.g., empty whitelist) and saw the same behavior, so there doesn’t appear to be any way to get the old behavior of prioritizing refresh rate matching. When I pull the logs, I’ll try to run tests with and without whitelisting just to see if the reasoning is different.

9

Thanks, but I suspect that it’s simple: without a white list find the ‘best’ resolution/framerate - with white list choose an exact match if available then find the ‘best’ resolution/framerate if not.

10

I apologize for the delay in getting the debug logs, but work absolutely swamped me the past week. The relevant logs are as follows, running with 1920x1080 @ 59.94 as the Kodi/GUI resolution:

Playback of 1080p25 file with whitelist in place:

2019-05-03 18:32:34.599 T:3606049504  NOTICE: Whitelist search for: width: 1920, height: 1080, fps: 25.000, 3D: false
2019-05-03 18:32:34.599 T:3606049504   DEBUG: Trying to find exact refresh rate
2019-05-03 18:32:34.600 T:3606049504   DEBUG: No exact whitelisted resolution matched, trying double refresh rate
2019-05-03 18:32:34.601 T:3606049504   DEBUG: No double whitelisted resolution matched, trying 3:2 pullback
2019-05-03 18:32:34.601 T:3606049504   DEBUG: No double refresh rate whitelisted resolution matched, trying current resolution
2019-05-03 18:32:34.601 T:3606049504   DEBUG: Current resolution doesn't match, trying default resolution
2019-05-03 18:32:34.602 T:3606049504   DEBUG: Default resolution doesn't provide reqired refreshrate, trying default resolution with double refreshrate
2019-05-03 18:32:34.603 T:3606049504   DEBUG: Default resolution doesn't provide reqired refreshrate, trying default resolution with 3:2 pullback
2019-05-03 18:32:34.604 T:3606049504   DEBUG: No whitelisted resolution matched
2019-05-03 18:32:34.604 T:3606049504  NOTICE: Display resolution ADJUST : 1920x1080 @ 59.94 - Full Screen (16) (weight: 0.000)

Playback of 1080p25 file with NO whitelist in place:

2019-05-03 18:39:14.531 T:3592594144  NOTICE: Whitelist search for: width: 1920, height: 1080, fps: 25.000, 3D: false
2019-05-03 18:39:14.531 T:3592594144   DEBUG: Whitelist is empty using default one
2019-05-03 18:39:14.532 T:3592594144   DEBUG: Trying to find exact refresh rate
2019-05-03 18:39:14.532 T:3592594144   DEBUG: No exact whitelisted resolution matched, trying double refresh rate
2019-05-03 18:39:14.533 T:3592594144   DEBUG: No double whitelisted resolution matched, trying 3:2 pullback
2019-05-03 18:39:14.533 T:3592594144   DEBUG: No double refresh rate whitelisted resolution matched, trying current resolution
2019-05-03 18:39:14.533 T:3592594144   DEBUG: Current resolution doesn't match, trying default resolution
2019-05-03 18:39:14.534 T:3592594144   DEBUG: Default resolution doesn't provide reqired refreshrate, trying default resolution with double refreshrate
2019-05-03 18:39:14.535 T:3592594144   DEBUG: Default resolution doesn't provide reqired refreshrate, trying default resolution with 3:2 pullback
2019-05-03 18:39:14.535 T:3592594144   DEBUG: No whitelisted resolution matched
2019-05-03 18:39:14.535 T:3592594144  NOTICE: Display resolution ADJUST : 1920x1080 @ 59.94 - Full Screen (16) (weight: 0.000)

For comparison, playback of 1080p24 (23.976) file with whitelist:

2019-05-03 18:32:57.931 T:3570983648  NOTICE: Whitelist search for: width: 1920, height: 1080, fps: 23.976, 3D: false
2019-05-03 18:32:57.931 T:3570983648   DEBUG: Trying to find exact refresh rate
2019-05-03 18:32:57.932 T:3570983648   DEBUG: Matched exact whitelisted Resolution 1920x1080 @ 23.98 - Full Screen (27)
2019-05-03 18:32:57.932 T:3570983648  NOTICE: Display resolution ADJUST : 1920x1080 @ 23.98 - Full Screen (27) (weight: 0.000)

And with NO whitelist:

2019-05-03 18:39:28.317 T:3592594144  NOTICE: Whitelist search for: width: 1920, height: 1080, fps: 23.976, 3D: false
2019-05-03 18:39:28.317 T:3592594144   DEBUG: Whitelist is empty using default one
2019-05-03 18:39:28.317 T:3592594144   DEBUG: Trying to find exact refresh rate
2019-05-03 18:39:28.317 T:3592594144   DEBUG: Matched exact whitelisted Resolution 1920x1080 @ 23.98 - Full Screen (27)
2019-05-03 18:39:28.317 T:3592594144  NOTICE: Display resolution ADJUST : 1920x1080 @ 23.98 - Full Screen (27) (weight: 0.000)

So, it appears to actually perform a long series of checks to try to get a close match, but the one check it doesn’t perform that v17 did is a check for the correct refresh rate with a higher resolution. Is there any chance of getting that check re-implemented within OSMC, or would that have to be an upstream Kodi fix?

EDIT: Further testing. I saw in the logs that it was trying to match refresh rates at the “default”/“current” resolution, so I tried switching the GUI over to 3840x2160 @ 59.94 and playing back the 1080p25 file. It worked just fine, as the following log shows:

2019-05-03 19:21:20.034 T:3600233184  NOTICE: Whitelist search for: width: 1920, height: 1080, fps: 25.000, 3D: false
2019-05-03 19:21:20.034 T:3600233184   DEBUG: Trying to find exact refresh rate
2019-05-03 19:21:20.034 T:3600233184   DEBUG: No exact whitelisted resolution matched, trying double refresh rate
2019-05-03 19:21:20.035 T:3600233184   DEBUG: No double whitelisted resolution matched, trying 3:2 pullback
2019-05-03 19:21:20.036 T:3600233184   DEBUG: No double refresh rate whitelisted resolution matched, trying current resolution
2019-05-03 19:21:20.036 T:3600233184   DEBUG: Current resolution doesn't match, trying default resolution
2019-05-03 19:21:20.036 T:3600233184   DEBUG: Matched fuzzy whitelisted Resolution 3840x2160 @ 25.00 - Full Screen (30)
2019-05-03 19:21:20.036 T:3600233184  NOTICE: Display resolution ADJUST : 3840x2160 @ 25.00 - Full Screen (30) (weight: 0.000)

I know you don’t recommend running OSMC on 2160p GUI resolutions due to the 1080p framebuffer, so it may still be optimal to try to implement the ability to check for matching refresh rates at higher resolutions than the target file (“fuzzy” matches in the log terms), but in the interim, leaving the OSMC GUI at 2160p59.94 at least results in proper refresh rate switching for all files.

Along that same line of thought, have you given any more consideration to adding the option to have OSMC render the GUI internally at 2160p so that the interface could look as clean and crisp as Kodi does on things like the NVIDIA Shield and other Android TV boxes?

11

So there is a version of Kodi that has all skin items in high res and render the screen at 2160p (no upscaling been done?) I believe many people would be interested in seeing that code pieces.

12

It may very well be that none of the Kodi builds render all of the skin elements in native 2160p, but having at least some of the key elements (e.g., text and cover art) render in 2160p makes a very significant difference in the overall crispness of the interface. Try setting up a Shield (or any other 4K Android TV box, presumably) and a Vero 4K next to one another hooked up to the same television, with both running Kodi on the default Estuary theme with the GUI set to 2160p, then toggle back and forth between the inputs and you’ll easily see that the Shield’s interface looks meaningfully sharper. That said, it may be partially because Estuary is a very abstract skin, so the skin image elements that would potentially need to be scaled internally wouldn’t be particularly noticeable.

When I first saw the difference when I got my Vero 4K+, I originally thought that it was just an issue with the different builds using different upscaling mechanisms, but when I went to take screenshots in Kodi to demonstrate the issue, I saw that the Android Kodi/SPMC screenshots were 2160p, while the OSMC screenshots were 1080p even when the GUI was set to 2160p, at which point Sam explained OSMC’s locked framebuffer.

Of course, I would still recommend the Vero over the Shield for Kodi purposes any day of the week, since the Vero is better when it comes to actual media playback, which is what really counts. But the fuzzier GUI is the sole area that I felt was a step downward when I moved from using the Shield as my primary playback device to using the Vero 4K, so I would be thrilled to see an option to configure OSMC to perform at least whatever partial native 2160p rendering is being offered on the Android builds.

13

I’ve noticed the same thing. I’ve read the code and this appears to be intentional. It does the following:

  1. Gets the list of resolutions/rates from the whitelist or a default set if there is no whitelist
  2. Look for an exact resolution/rate match
  3. Same but with matching double the video rate rate
  4. Same but with 3:2 pullback rate
  5. See if the current resolution resolution is equal or higher and rate matches video rate, double video rate, or 3:2 pullback (The 3:2 pullback was removed from the code yesterday)
  6. Check desktop resolution matching the framerate, double, or 3:2
  7. Finally fail.

I investigated this because I noticed that my TV wasn’t switching from 1080p@60Hz when the content was 720p@24.000Hz (yes, that’s not 23.976). That is because the current resolution with 3:2 pullback was matching. If I were to put the TV into 1080p@59.97Hz, then it would switch (since the 3:2 pullback no longer matched and it would fallthrough to step 6).

It seems to me that the best action would be a check between 4 and 5 to see if there is an entry of higher resolution (than the source) that is an exact, double, or 3:2 match to the rate.

Note: I mentioned the 3:2 pullback check on the current resolution was removed yesterday so that actually would solve my issue but not yours.

14

Let me get this straight.

You have whitelisted 720p24 and it didn’t switch to that? ie failed at step 2?

15

I have whitelisted 1080p@24.000Hz. I don’t have a 720p@24.000Hz available and I’ve not whitelisted anything other than 1080p and 2160p resolutions. So step 2 fails because it’s not an exact resolution match.

If I set the UI to 1080p@60Hz, it will not switch to 1080p@24.000Hz for 720p@24.000Hz content because 2-4 don’t match the resolution, and then in 5 the resolution is sufficient and the rate matches 3:2 pullback (24.000*2.5 = 60.000±0.01). Note that the file I linked has a commit yesterday that will change this behavior to fix my issue but not fix the OP’s issue.

If I set the UI to 1080p@59.94Hz, it will switch to 1080p@24.000Hz for 720p@24.000Hz content because again 2-4 doesn’t match the resolution, but 5 the rate doesn’t match (24.000*2.5 ≠ 59.94±0.01), so it falls through to 6 where it checks the desktop resolution (which is 1080p) and finds an exact match on the refresh rate of 24.000Hz.

So similarly to the OP, if after it fails to find a resolution/rate match, if it then searched for sufficient resolution just match the rate before looking at the current, it’d result in video scaling but matched rate in more cases.

Edit: I was saying 59.97 instead of 59.94. Corrected this.

16

Got it, now. You didn’t say what you expected it to switch to first off.

This whitelisting thing is a can of worms, isn’t it?

17

For sure. The tricky part seems to be that there are really two factors to consider when trying to match playback resolution/refresh rate: what it can switch to (i.e., the whitelist) and what it should switch to (i.e., whether the user would prefer to match refresh rate or resolution when there isn’t an exact match).

I suppose the first question moving down the path toward a resolution would be whether it’s safe to assume that most users would favor a matched refresh rate with a higher resolution (assuming they already have said res/rate whitelisted), or whether it needs to be a more explicit option (e.g., a setting near the whitelist saying something along the lines of “Prefer matching refresh rate”).

18

I get the same behavior with and without the whitelist. Mostly this is because I’ve not excluded any resolutions it will preferentially use over the ones I have selected. This is due to the order in which Kodi 18 is selecting randr; after it has considered exact resolution matches, it considers the current mode and then other modes with the desktop resolution. I think it should consider modes matching the refresh rate (and of higher resolution than the media) before the current mode.

Occasionally my Kodi fails to change refresh rates, usually due to failure in getting the EDID data or the above but I think I’ve resolved the former. Anyway, when it does, I can see within the first minute or two and I ask myself whether it failed to match the refresh rate or whether this was a bad encoding. I check the refresh rate on the receiever’s info popup and every time it has been refresh rate not matching.

So my vote is: match refresh rate (of equal or higher resolution) over matching resolution.

19

If there is no whitelist, Kodi constructs its own ‘default’ then uses the same logic, which is different from what it used in v17.

21

I have made a revised Kodi which should do what you are after, if you are willing to test. Here https://collab.osmc.tv/s/Ieeuf6C2ZPNHBJc you will find a kodi.bin to download.

If you go

sudo cp /usr/lib/kodi/kodi.bin /usr/lib/kodi/kodi.bin.release
sudo systemctl stop mediacenter
sudo cp <whereveryousavedit>/kodi.bin /usr/lib/kodi/
sudo chmod +x /usr/lib/kodi/kodi.bin
sudo systemctl start mediacenter

it will be ready to test. The idea is if you whitelist 2160p25 then your PAL stuff should play at that.

Can you let me know if it works and grab a debug log of what happens when there is no whitelist and when you whitelist 2160p25. I can’t test it here because my TV does do 25Hz at all resolutions.