[Testing] Kodi 18.0 Leia beta versions now available for RetroPie!

[Rascas]

@psyke83 said in [Testing] Kodi 18.0 Leia beta versions now available for RetroPie!:

Thanks, but I personally don't like using rpi-update due to the way it dumps the firmware libraries into /opt/vc/; for example, in the case of stretch, it installs duplicate libraries that are supposed to be phased out (libGLESv2, libEGL etc.), which can cause compatibility issues.

Well I think this does not happen anymore, that happened only in the time that RPi Foundation decided to rename the libraries due the open source graphics driver getting more popular, and there was some mistakes and, of course, everything that depended on them had to be fixed/changed.

But yes, rpi-update should only be used for testing purposes in my opinion, it gets the bleeding-edge kernel and firmware. And again, this fix shouldn't take long to reach the repos.

[hhromic]

@psyke83 said in [Testing] Kodi 18.0 Leia beta versions now available for RetroPie!:

@BuZz

Users on the Steam forum also reported black screen issues caused by overscan_scale=1 for the steamlink app, which is why they implemented a block in the scripts.

Even though I can't reproduce the issue re: the steamlink (and haven't yet tried the kodi rc), perhaps it would be a good idea to move that configuration out of emulationstation and into the raspbiantools script as an optional tunable? I'd be happy to work on that and send a PR if you're interested.

That is very tempting, I also have thought of not forcing such an option in EmulationStation, specially for people who doesn't need overscan (like me). It should be optional indeed. If I remove the setting manually, it will be put back when ES is next configured, e.g. during update.

However, the overscan settings seem to be not very intuitive in the RPI. For example I believe that the disable_overscan config is broken in current firmware as it is not respected, i.e. it doesn't matter what you set, you always get overscan enabled.

The overscan_scale setting is actually only needed for displays that require overscan, probably most CRT setups and some weird HDMI displays. The reason is that the overscan settings are only applied to the framebuffer, not the dispmanx layers where ES is rendered. Without overscan_scale, ES is not displayed respecting the overscan adjustment settings. For displays that do not require overscan, this setting produces no visual difference but still incurs in scaling processing by the GPU and hence overscan_scaleshould not be used.

I think the best approach would be to put an option in the ES script GUI to enabled/disable overscan scaling (and explaining that it's only necessary for setups that require overscan adjustments) and not blindly force this during the configure phase. Actually, like @psyke83 suggested, better would be in a more general configuration scriptmodule, like raspbiantools. However raspbian does not only run for raspberry pies (I think ORA too?). How about in the retropiemenu instead?

[hhromic]

@hhromic said in [Testing] Kodi 18.0 Leia beta versions now available for RetroPie!:

However, the overscan settings seem to be not very intuitive in the RPI. For example I believe that the disable_overscan config is broken in current firmware as it is not respected, i.e. it doesn't matter what you set, you always get overscan enabled.

Ok I got an answer from popcornmix regarding how disable_overscan actually works in https://github.com/raspberrypi/firmware/issues/1079#issuecomment-444467449:

disable_overscan=1 removes the default overscan settings.
These are:
48 pixels on each edge for HD CEA modes
32 pixels on each edge for SD CEA modes
0 for DMT modes (which displays don't overscan).

You can still apply additional overscan settings which are added to the default.

So yes, overscan_scale should be activated only if necessary to avoid extra processing.

[BuZz]

@hhromicIt is only enabled if needed as it's only active if disable_overscan=0 afair. Currently if "overscan" is needed, this option is required or ES will render offscreen. We would need some code in ES to be able to adjust screen position like on Kodi.

we could make sure overscan is disabled by default (Maybe it already is, I can't remember), but I believe we will have a lot of people complaining if this option is removed without extra code for ES.

I have a screen which requires this option. On my other screen i have disable_overscan=1 so the option is ignored.

[hhromic]

@BuZz said in [Testing] Kodi 18.0 Leia beta versions now available for RetroPie!:

It is only enabled if needed as it's only active if disable_overscan=0 afair.

I thought the same too, but see my previous post. As popcornmix clarified, the disable_overscan option actually just sets all overscan margins to 0 in one setting, it doesn't disable the overscan engine itself. There seems to be no option to do that.

Currently if "overscan" is needed, this option is required or ES will render offscreen.

Exactly, as you say, only if overscan is needed by the display.

We would need some code in ES to be able to adjust screen position like on Kodi.

Only if the intention is to get rid of setting overscan_scale. Otherwise, for users that need overscan, the scaling by the GPU is the cost to pay until ES can do overscan correction itself natively. I don't think is a big deal currently.

we could make sure overscan is disabled by default (Maybe it already is, I can't remember)

By default Raspbian Stretch comes with disable_overscan commented out (so it doesn't change the default overscan margins), and as mentioned there is no way to "disable overscan" entirely. According to popcornmix, the default margins are:

48 pixels on each edge for HD CEA modes
32 pixels on each edge for SD CEA modes
0 for DMT modes (which displays don't overscan).

but I believe we will have a lot of people complaining if this option is removed without extra code for ES.

True, users would start complaining, however I don't think the current behaviour needs to be changed for them (activating overscan_scale by default). Instead, I think we just need to improve the ES scriptmodule to handle the case of users that do not want/need overscan_scale and do not force it at every update/configure. This should be relatively simple to do and accomodates all cases.

I have a screen which requires this option. On my other screen i have disable_overscan=1 so the option is ignored.

The option is not ignored, just visually not perceptible. The GPU is still doing 1:1 scaling.

[BuZz]

@hhromic if you are right then why did the Kodi bug only happen when this was set and disable_overscan is 0. Why doesn't the firmware disable it if it's not needed with overscan disabled / set to 0? Note we have had this discussion years ago and it's set for a reason. If we disable it we will get more user complaints that stuff is rendered offscreen.

I'm not yet convinced we should change it, not until we have a way to make es/retroarch obey the overscan settings.

We could add a configuration to disable the setting. But it's easily done my editing the config.txt. I'm reluctant to change defaults though (not saying that you are asking for that - I misread your post initially).

[hhromic]

@BuZz the Kodi bug seemed to be a problem with the overscan_scale engine itself, not the overscan settings overall, the commit that fixed the firmware for the issue states:

https://github.com/raspberrypi/firmware/commit/afd824ac32ab1f3bf8b462178770253f8757bf1f

firmware: dispmanx: Also apply overscan_scale when clamping to screen
See: https://forum.kodi.tv/showthread.php?tid=338052

I think what happens is that when all the overscan margins are 0, for example when disable_overscan=1, then the overscan_scale engine is doing 1:1 and the bug doesn't manifest.

I can't try myself (I don't have KODI installed) but I bet these settings also trigger the bug:

disable_overscan=1
overscan_left=40
overscan_right=40
overscan_top=40
overscan_bottom=40
overscan_scale=1

Also I bet that if you move disable_overscanto the bottom, the bug doesn't happen because it will reset the overscan margins back to 0.

Anyway, to be clear, I'm not trying to convince you to remove setting overscan_scale, but I'm trying to convince you of the need to add functionality to not force it when users don't need it. For example something like : if installing ES for the first time and overscan_scale is not set, then set it, otherwise do not touch it.

Edit Just realised you edited your post, yes, adding a configruation to disable the setting and making sure the script respects the setting. Editing the config.txt file manually doesn't work because on the next update/configure, ES will again set overscan_scale back to 1.

Edit2:

Why doesn't the firmware disable it if it's not needed with overscan disabled / set to 0?

That's a question for the firmware mantainers :) I also agree with you that it is the expected behaviour given the option name. I already raised an issue asking for the documentation to be updated to better explain this. The option should be named overscan_reset or such :/.

[BuZz]

@hhromic I will test your settings.

I would be willing to set the option as part of image building and remove it from ES. Then those that change it won't get it set again. Would that suffice?

No need for a PR though as I'd like to do the changes.

[hhromic]

@BuZz yes, that idea of only setting the overscan scale on image building sounds good indeed!

Btw, I noticed that the ES scriptmodule also configures gpu memory alongside overscan scale in config.txt. Perhaps that also makes sense to be done on image building? It falls under the same shortcoming: if users change their gpu mem config, the settings get reset on ES update/configure.

[BuZz]

@hhromic yep. I'll change it. This is code that dates back to the very early days of RetroPie.

[CapNinja]

Hi, did a fresh install today and my retropie is up to date.
I've installed this kodi today but it did not appear on my ports section or anywhere in es screen, what do I need to do?

[Rascas]

@CapNinja Install Kodi in RetroPie-Setup.

[ParadoxGBB]

I've had great success in removing the overscan setting... if it's true that it should have not been set for hardware that doesn't need it, I'm curious whether I really do. Does anyone know if there's graphic patterns to check whether overscanning is needed?

I had some time to look closer at the slideshow / picture issue I outlined earlier. The crash appears to happen for all pictures taken with my camera hardware. I opened up a thread with debug logs and additional notes on the Kodi picture forum website here:

https://forum.kodi.tv/showthread.php?tid=338157

Otherwise, things look great.

[Rascas]

@ParadoxGBB said in [Testing] Kodi 18.0 Leia beta versions now available for RetroPie!:

I've had great success in removing the overscan setting... if it's true that it should have not been set for hardware that doesn't need it, I'm curious whether I really do. Does anyone know if there's graphic patterns to check whether overscanning is needed?

https://retropie.org.uk/docs/Overscan/

@ParadoxGBB said in [Testing] Kodi 18.0 Leia beta versions now available for RetroPie!:

I had some time to look closer at the slideshow / picture issue I outlined earlier. The crash appears to happen for all pictures taken with my camera hardware. I opened up a thread with debug logs and additional notes on the Kodi picture forum website here:

https://forum.kodi.tv/showthread.php?tid=338157

Otherwise, things look great.

I can't help you much with that, it looks like the decoder doesn't like pictures from that camera, probably a bug. Let's see what people says about it in Kodi forum.

PS: Ask in your Kodi forum post to move it to the Raspberry Pi section, as it seems a RPi only problem.

[ParadoxGBB]

@Rascas , you're likely smarter than me (and this might be why I haven't gotten any bites yet on the thread yet), but so far I don't have any real evidence that this is a RPi only problem, although it'd make sense it'd be an underlying dependant package that does the parsing. If anyone reading with a non-RPi install would be open to trying to open up a picture for my curiosity to see if we got a crash, I'd be much obliged and would gladly provide one.

Today I got both Netflix and Amazon VOD working, and I just wanted to write down a few notes:

1. For Amazon, like many, I was having trouble signing in with captcha-like challenges. Like some suggestions I read, I tried setting USA as region / language explicitly and replacing network.py with a different version. At the end, what worked for me was deleting the addon userdata files (\configs\ports\kodi\userdata\addon_data\plugin.video.amazon-test*) and re-installing the addon. I restarted Kodi afterwards for good measure.

2. For Netflix, for my particular RetroPie 4.4 image I didn't have pip installed. If you're not a raspberian / linux guru like me and want to know how to install it, you can hit F4 to get in the terminal and install via:

$ sudo apt-get install python{,3}-pip

And then you successfully execute:

$pip install --user pycryptodomex

After then I did some shaking but then I could log in. Like other folks have observed for some reason some videos are coming up as the default language dubbed in German. I went into the general Kodi settings and explicitly selected languages and regions (region / timezone was not explicitly set). Also like a few folks have observed if you start Kodi and dive right into the Netflix plugin it will fail... you'll need to wait a bit (or try again).

Overall, it's great to have these streaming options, hats off to the developers!

[Rascas]

@ParadoxGBB yes, please provide one or two fotos to test.

[ParadoxGBB]

@Rascas

Thanks a ton, appreciate it. It's zipped to ensure binary integrity. Let me know what you see.

https://1drv.ms/u/s!ArVgGNNmR7mK2IFHnd0B7B9RV5fByw

[Rascas]

@ParadoxGBB Ok, I have tested that foto and I can confirm that Kodi 18 crashes when trying to vizualize it. It is for sure a RPi only problem/bug because it does not happen on Ubuntu x86-64 for example. Unfortunately, I can't fix it, i think it is a decoder/firmware bug, only the guys from the RPi Foundation can fix it.
I recommend you to report that in your Kodi forum post, Dom (popcornmix) will fix it almost for sure.

[ParadoxGBB]

@Rascas Thanks for this, poked the thread with a few at mentions.

Just curious, Leia RC2 dropped on 12/4. Anyone know if a refresh for the RPi is coming soon as well?

[Silent]

It appears like RC3 is the newest, and Kodi is nagging about that - although admitedly I don't know if it's nagging cause there is a new version for rpi, or just in general...