[TESTING] Linux 4.9 kernel and improved video stack for Vero 4K / 4K +

I’ll wait a bit in case you need me to check anything about it.

Ah. I’ll try this. Thanks, @tanio99!

I don’t use suspend anymore @bmillham

One question before I install this test version. I have been using the 4.9 kernel (to use 3D) before and it was fine, but due to other reasons I switched back to latest stable version some time ago.

When I install this buster/4.9 test version, will it be possible to upgrade to stable buster/4.9 version at a later moment or do I need to do a complete a re-install at that moment? I do realize a re-install is necessary for a downgrade, but what if buster/4.9 stable release is released?

@tanio99 you’re correct. Left it unplugged for an hour and turned right back on. Thanks :smile:

Here’s the list of things I’ve fixed since the last testbuild:

  • fixed hardware decoder underrun issue (reproducible with the ‘Tyler Rake’ sample)
  • fixed issues with small frame sizes where Kodi stopped sending data because it thought the hardware decoder has enough material to start decoding
  • fixed an issue where the decoder turned off video output if a corrupt stream was detected (reproducible with the ‘lagoon’ sample)
  • 3D subtitle depth issues (thanks to @angry.sardine for his testing help)
  • fixed an issue with the latest makemkv tool which did not store the ‘private data’ of 3D MVC streams as it used to
  • fixed garbage playback of 3D MVC if the file is named like whatever.3D.MVC.mkv (and probably no stereoscopic type set)
  • fixed an issue when playing an SDTV followed by a 3D MVC stream resulted in garbled video output
  • fixed a race condition in the Kodi logging module which could crash Kodi during shutdown


I’ve a bit of a problem with the new beta I’ve upgraded yesterday to due to having some problems with scenes hanging with VP9 (via yt plugin) and hevc.
The first time I started the player after the upgrade I got a greenish screen when started the first video, all others were the same. Then after the reboot from the Kodi interface I’ve manged to play some files.
After putting the player to sleep and starting again, as soon as I started skipping the file a was watching a few times the screen or rather the picture from the decoder turned green.
Now I get only the black screen no matter what the file is.

All of the time (with one exception) the rest of the Kodi interface during playback is rendered properly, so it doesn’t seem like the problem is somewhere in the video decoding/rendering part of the process.

One thing I notice in dmesg is:
[ 148.516973] 0: MH264 the TEE fw loading failed, err: ffff000

The full log is here: https://paste.osmc.tv/ipefizoxiv

Let me know if you need any more info :slight_smile:

apt reinstall vero3-userland-osmc did the trick for getting rid of [ 148.516973] 0: MH264 the TEE fw loading failed, err: ffff000, still interesting what was the root cause. For now everything seems fine.

Your userland package was either outdated or not installed properly, which meant that the video ucode was not being loaded properly.

Yes. The plan was to provide a smooth upgrade.
In fact, you’ll just remove the ‘videoimprovevero49’ repository and update as normal.

Yup, I may have messed up something as I had to downgrade the mediacenter package at some point. What was strange is that upgrade via apt was successful and no problems occurred. Thanks for checking and explanation.

That just means you installed an older version of the package, which won’t work with the new secureOS we just released

Just smoothly upgraded to Buster with 3D and 4K Video now playing fine. However after upgrading to the latest System, then to Buster the remote control commands returned to the default Vero 4K+ remote. However I could not change the default remote back to Xbox 360 using the updated Remotes Screen in MyOSMC. Has anybody else experienced this problem? What am I doing wrong?

Well the OzWeather app creater has thrown it back to you here

2020-09-21 15:22:56.239 T:3367997664 ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<-- - NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS! Error Type: <class 'socket.gaierror'> Error Contents: [Errno -2] Name or service not known Traceback (most recent call last): File "/home/osmc/.kodi/addons/weather.ozweather/default.py", line 327, in <module> getForecast() File "/home/osmc/.kodi/addons/weather.ozweather/default.py", line 309, in getForecast forecast(locationUrlPath, radar) File "/home/osmc/.kodi/addons/weather.ozweather/default.py", line 226, in forecast buildImages(radarCode, updateRadarBackgrounds, backgroundsPath, overlayLoopPath) File "/home/osmc/.kodi/addons/weather.ozweather/resources/lib/bom.py", line 201, in buildImages ftp = ftplib.FTP("ftp.bom.gov.au") File "/usr/lib/python2.7/ftplib.py", line 120, in __init__ self.connect(host) File "/usr/lib/python2.7/ftplib.py", line 135, in connect self.sock = socket.create_connection((self.host, self.port), self.timeout) File "/usr/lib/python2.7/socket.py", line 557, in create_connection for res in getaddrinfo(host, port, 0, SOCK_STREAM): gaierror: [Errno -2] Name or service not known -->End of Python script error report<--

So what do I do to reproduce a problem?
I’m willing to test firsthand.

Install the OzWeather app and it won’t work?

Struggling to see what changes could possibly cause this in our side. A kernel update (which is what this post is about), will certainly not be the cause.

That looks like DNS resolution failure to me.

I run ozweather and have no issues since the upgrade

It was working fine before the upgrade.
I did also enable the DoT encrypted DNS servers to my router and given your comment about DNS that might be it. Must admit I’m struggling to force the Vero to use and for DNS…

You could try to ping the ftp server from OSMC. SSH in and:

ping -c1 ftp.bom.gov.au

You won’t get a response to the ping, but you should get something like this:

osmc@yeti:~$ ping -c1 ftp.bom.gov.au
PING ftp.bom.gov.au ( 56 data bytes

--- ftp.bom.gov.au ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

That will show if you are getting DNS resolution.

Bad Ping Address!!