Recent update messed up overscan

Has there been a recent update within 1-2 weeks that would mess with overscan options?

I had mine setup perfectly from the config.txt so in KODI gui it was all lined up and playing videos was the same, then noticed it was out the other day as when Pausing the word ‘Paused’ at the top was off the screen.

The settings in config.txt are still there and when ‘playing’ with calibration within KODI I then align the GUI and the videos end up with black borders!

I think Kodi has screen calibration for the UI and a different setting for playback.

Screen calibration is in the menu when you are playing a video.

Running “tvservice -m CEA” I get :-

Group CEA has 15 modes:
mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
(native) mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
mode 6: 720x480 @ 60Hz 4:3, clock:27MHz x2 interlaced
mode 7: 720x480 @ 60Hz 16:9, clock:27MHz x2 interlaced
mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
(prefer) mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive
mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced
mode 21: 720x576 @ 50Hz 4:3, clock:27MHz x2 interlaced
mode 22: 720x576 @ 50Hz 16:9, clock:27MHz x2 interlaced
mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive

My TV is 720P, what’s the difference between “Prefer” and “Native” and which do I want to force it into with
hdmi_group=1
hdmi_mode=4,19?

The only difference I see is 50Hz or 60Hz, the back of my tv has both and KODI seems to work with both.

I’m trying to set a good baseline to then work with overscan and my alignment issues with the video and gui.

Overscan is usually independent of resolution - eg it’s either on or off, so manually specifying a boot resolution probably won’t do much to help.

As always the best solution by far is to disable overscan on the TV - which most modern HDMI TV’s allow you to do on a per input basis. (You might still want overscan from your cable box for example for watching SD channels)

Any overscan/calibration settings in Kodi/OSMC that you use to compensate for a TV that is overscanning is only going to degrade picture quality.

PS I’m not aware of any reason why recent updates would affect screen calibration or overscan settings.

I cannot turn off overscan on my TV it is impossible I have tried many times before even working out the engineer service menu and looking in there.

I know video calibration within KODI is bad and had already set up the overscan settings in the /boot/config.txt file but something in a recent update screwed all this up.

After spending an hour or so playing with settings I’m back to :-
disable_overscan=0
overscan_scale=1
overscan_left=32
overscan_right=32
overscan_top=18
overscan_bottom=20

Which is a little different that I had before, also KODI seems to totally ignore these settings unless I use the line overscan_scale=1 which it didn’t before and maybe the difference. I know the Pi is taking them as if I enter crazy figures I can change the boot OSMC screen but once in KODI it just ignores it, I set the calibration back to 0 and even deleted the /home/osmc/.kodi/userdata/guisettings.xml file at one point.

All working now but odd…

As I said, nothing changed in the updates that should affect overscan. Possibly you lost your guisettings.xml file due to it being corrupted or Kodi crashing, which would revert your Kodi preferences back to defaults.

I could be wrong, but I don’t think the overscan settings in config.txt have any effect in Kodi - they only affect the splash screen and programs running at the console, but not Kodi itself.

In Kodi the only options you have are Settings->System->Video Output->Video Calibration (which calibrates video playback) and Settings->Appearance->Skin->Zoom, which will scale the GUI.

Overscan settings in the config.txt affect Kodi as I’ve just spent a chunk of time playing with them and rebooting till it was right :slight_smile: I know as I was running up and down the stairs to go from the PC to the TV :smile:
The only difference seems to be the requirement of overscan_scale=1 now whereas before it didn’t seem to need this.

My Video calibration settings are all 0,0 but it fits the screen perfectly in the GUI and playing a video.

Beezarre :smile:

I have the same problem: after the last upgrade to RC3 on my RPi2 the new kernel (passed from 3.18.10-1 to 3.18.13-1) isn’t taking into account the overscan parameters.

The overscan config I’ve been using for years is the following (customized for my TV):

disable_overscan=0
overscan_scale=1
overscan_right=-20
overscan_bottom=-15
overscan_left=7
overscan_top=-15
sdtv_mode=2
sdtv_aspect=1

That config has been working fine with all the releases of Raspbmc (on my model B) and OSMC (on my RPi2), up to the last upgrade to RC3. Then the borders are out of the limits of the screen (i.e. I’m missing the info around the corners in the GUI, like the time, or the favourites icon, and the same for the videos played), no matter of the overscan border parameters I setup to re-adapt the screen borders. The only parameter that seems to take into account is the overscan_scale, which I’ve been always activated along all the releases. Now, if I setup the overscan_scale, the effect is even worse, so I have to disable both, overscan and overscan_scale, and play with the Kodi GUI zoom factor, which is far from a good solution, compared to the fine degree of accuracy using the overscan parameters.

Finally I’ve checked the guisettings.xml file in search from some old unwanted display configuration, but nothing to note there; everything seems to be ok and no config about the display borders or resolution exists.

Is there any way to take the overscan values from the config.txt file into account again? I’m thinking to go back to RC2 in the meanwhile, although I think is not a good idea to get stuck into an old release to overcome the problem…

The rest of params from the config.txt file (including those for the licenses) are working OK.

Thanks a lot in advance for the help and hints,

jamontes.

Config.txt entries are handled by the Raspberry Pi firmware not the Linux kernel, there was also a Pi firmware update between RC2 and RC3, it’s much more likely to be that, if anything.

This is contained in the package rbp-bootloader-osmc. The previous version was 1.0.2-0 and the current version is 1.0.3-0.

Check to see if you still have the old version in your apt cache - this is in /var/cache/apt/archives/

If you have it you should be able to manually downgrade the firmware to the previous RC2 version by doing:

sudo dpkg -i  /var/cache/apt/archives/rbp-bootloader-osmc_1.0.2-0_armhf.deb
reboot

Please also run the following command before and after the forced downgrade, to capture the actual firmware versions and post them here:

vcgencmd version

This is only a temporary workaround to see if this is indeed the issue. Please let us know the result.

CC @popcornmix

Hi DBMandrake,

Thanks a lot for your detailed explanation and help. Now I realize I’ve had a miss-concept with the way the config.txt file is handled by the system at boot time.

I’ve checked the directory /var/cache/apt/archives searching for the rbp-bootloader-osmc_1.0.2-0_armhf.deb file, but the only file I’ve found is the rbp-bootloader-osmc_1.0.3-0_armhf.deb.

The reason to this is that I’ve made a fresh install directly from RC2 (i.e. the upgrade from from RC2 up to RC3 is the first one), so there’s no rbp-bootloader-osmc_1.0.2-0_armhf.deb archived, I’m afraid.

I’ve executed a “find” command just in case, but didn’t find that file into the filesystem (only the /var/lib/dpkg/info/ files appeared regarding the installation of the latest one). Besides of that, I’ve searched that deb file through the mirrors on internet but didn’t find the wanted release. All the mirrors pointed to the last deb release (for instance, in https://ftp.uni-erlangen.de/raspbmc/osmc/apt/pool/main/r/rbp-bootloader-osmc/ or https://ftp.fau.de/raspbmc/osmc/apt/pool/main/r/rbp-bootloader-osmc/).

On the other hand, this is the output from the vgencmd command:
root@osmc:~# vcgencmd version
May 13 2015 14:58:12
Copyright (c) 2012 Broadcom
version 8e0e0dbfe92be77d6355082451280d32f5bf0ff3 (clean) (release)

If you can pass me the debian package file by any way (or let me know where I can download it) I’ll be glad to test it asap on my RPi2 RC3 and let you know with the results.

Once again, many thanks for all your help and support.

Best regards,

jamontes.

I’ve uploaded a copy of the old bootloader file on my dropbox account, you can download it directly to your osmc home directory with:

wget https://dl.dropboxusercontent.com/u/7826218/Forum%20attachments/rbp-bootloader-osmc_1.0.2-0_armhf.deb

Then install it with:

sudo dpkg -i rbp-bootloader-osmc_1.0.2-0_armhf.deb

Please let us know if it resolves the overscan issue and the version reported with vcgencmd version. Thanks.

Hi DBMandrake,

I’ve downloaded and installed the old bootloader from your dropbox link, and after rebooted it works as expected.

This is the vcgencmd output after the installation and reboot:

root@osmc:~# vcgencmd version
Apr  6 2015 13:30:31 
Copyright (c) 2012 Broadcom
version 52e98d667b8b6ef27a2df8d817807701057bb30d (clean) (release)

Now the aspect video is OK, as before to the RC3 upgrade. The only difference is the warning message about new updates in the main screen :wink: but I think is an acceptable side effect until the next firmware release is ready with the fix.

Once again, I really appreciate all your help and time in helping me to solve the problem (and I’m talking on behalf of my family as well).

Best regards,

jamontes.

Thanks. That would seem to confirm that the overscan options in config.txt not working is a problem introduced some time between the April 6 and May 13 versions of the firmware.

Any ideas @popcornmix ?

The normal overscan_left/overscan_right/overscan_top/overscan_bottom only apply to the framebuffer (e.g. console and X gui). They have never applied to other overlays, like video or opengl (which are used by Kodi).

overscan_scale=1 is a hack that I don’t recommend using. It attempts to scale all the other overlays (including video and opengl). But it is a bad thing to do as the host application doesn’t know about it.

Lets imagine you have a native 1280x720 display, but it is badly set up such that only the central 1200x640 pixels are visible. You have two choices here. You can use the calibration option in Kodi’s gui, which will result in the GUI being rendered at a 1200x640 and output unscaled. Or you can use overscan_scale=1 which results in the gui being rendered at 1280x720 and being rescaled by the Pi to 1200x640. This scaling will degrade the image and make it look more blurry.

Because overscan is configured in TV you will likely get an additional resize to it’s native resolution. You need to disable overscan in the TV menus to avoid that, but the presence of “overscan_scale=1” is adding an extra rescale to the displayed image.

There was a firmware fix 12 days ago where the overscan settings were incorrectly applied. The behaviour before then was a bug, so it may be that you have to update the overscan_* settings you are using to compensate for that. However I believe the new settings are correct, and the old settings were incorrect.

In general my recommendation would be in order of preference:

  1. Ensure a 1:1 scaling in TV and disable all overscan/calibration settings. This gives you the best image quality. Video that matches native resolution of TV will be unscaled. Other sizes will be resized once by Pi.
  2. Use the calibration settings inside kodi. The GUI will be resized by TV once, but not by Pi. Video will likely be resized twice (by Pi and TV).
  3. Use overscan_scale. The GUI will be resized by TV and again by Pi. Video will likely be resized twice (by Pi and TV).