[TESTING] Kodi 18 (Leia) builds for Vero 2 & 4K


There’s also some issues with the 122 kernel, i had been using the 121 kernel until this update and running cat /sys/class/amhdmitx/amhdmitx0/config gives the following depending on the content:-

|           |          | 121 Kernel | 122 Kernel |
| GUI       | EOTF     | SDR        | SDR        |
|           | Depth    | 8bit       | 10bit      |
|           | CS       | YUV444     | YUV444     |
| SDR Video | EOTF     | SDR        | SDR        |
|           | Depth    | 8bit       | 10bit      |
|           | CS       | YUV444     | YUV444     |
| HDR Video | EOTF     | HDR10      | HDR10      |
|           | Depth    | 10bit      | 10bit      |
|           | CS       | YUV422     | YUV444     |

Notice that the 122 kernel outputs 10bit regardless of content and HDR10 uses the 444 colour space instead of 422.


Yes. That’s how it’s designed. Some people’s displays won’t display properly at 422,10bit so that was reverted. The idea is that we set the bitdepth according to display’s caps to avoid extra delay when playing content at the same resolution as the GUI.

If anyone notices a difference between a 8-bit video played at 8-bits and one played at 10-bits let us know. I can’t tell the difference on my three screens (two of them are deep colour, one of those is HDR)

Similarly, if anyone gets good results at 422,10bit and not at 444,10bit we can look at that again.

To override bitdepth: echo 8bitnow | sudo tee /sys/class/amhdmitx/amhdmtx0/attr

IIRC, you can’t override colourspace with attr. Sorry.


Ok, I haven’t noticed a difference visually, apart from the fact I now have to use a different HDMI lead as the one I was using worked fine at 10bit 422 but loses sync at 10bit 444.


Good good. Thanks for the feedback. 4k@60Hz should be playing at 420 with the same bitrate as 4k@24Hz 444. Both should need the better cable.


I’ll do some more testing later, I’m in the middle of doing a complete reinstall just to make sure the issues I’m having with 17.8.346 aren’t due to the fact I’ve been doing quite a lot of switching between the 119, 121 and now 122 kernels…

Well, I’m trying to backup my Vero over ssh but 5 minutes into the copy it keeps dropping the connection… Urgghhghg :rage:


Ok, so after doing a complete reinstall of the official 2018.08-1 image then updating to 17.8.346 I can confirm the same problem, a couple of seconds of scrolling through any menu causes Kodi to crash and restart.

I’ve downgraded back to 17.8.345 which works perfectly.

As this is a fresh install its on the 117 kernel.


Also some reports of the same issue on the rpi version. Hopefully will be fixed upstream soon.


Ok, As long as I know it’s not just me :slightly_smiling_face: And hey a big thanks for taking the time to do these builds for us :smiley:


Two hours after installing new 122 kernel and newest upgrade (I didn’t do nothing…idle) vero 4k bootloop :frowning:

Best regards


That’s why these builds are still experimental


I’m on Kodi beta versions and tonight’s update broke Kodi. Can I roll it back to the last one I was on? It feels like I should remember how to do this, but it’s been a long day. Sorry.


Yes, you can roll back. See first post.


17.8-347, 26 Oct 2018: Based off OSMC commit (e38cb056c) and xbmc (a715043c11)


  • [cmake/Xcode] - fix missing text and icon resources when using target Xcode (PR:14693, 1 commit, 1 file changed)
  • fixed: add-on creation is not thread safe (PR:14679, 1 commit, 2 files changed)
  • add mime types for heif/heic (PR:14680, 1 commit, 1 file changed)
  • Fix crash on exit when checking of libgpg-error lock object size. (PR:14683, 1 commit, 1 file changed)
  • EGLUtils: breakup EGL init process (PR:14652, 1 commit, 7 files changed)
  • windowing/gbm: use CFileHandle to handle the fd (PR:14673, 1 commit, 4 files changed)
  • [GBM] support 10bit output modes and other fixes (PR:14515, 4 commits, 8 files changed)


  • [TS] allow short 001 start sequence before SPS (missing byte in extra-data) (a216c05)


  • 4.4.0: RDS support and minor changes (PR:381, 3 commits, 6 files changed)


  • [depends] rapidxml: convert patch to crlf line endings (PR:201, 1 commit, 1 file changed)

Includes latest addons: inputstream.adaptive (df30a23, +7), inputstream.rtmp (cf31ec5, +1), peripheral.joystick (2196056, +3), peripheral.xarcade (91567dd), pvr.argustv (e3f9781, +a3), pvr.demo (998d890, +1), pvr.dvblink (cba64fc, +4), pvr.dvbviewer (34c9641), pvr.filmon (08c389e, +4), pvr.hdhomerun (ea8c4e2, +1), pvr.hts (b13a570, +1), pvr.iptvsimple (2134467, +3), pvr.mediaportal.tvserver (bca5311, +2), pvr.mythtv (7acc914, +2), pvr.nextpvr (9b06fcd, +1), pvr.njoy (5605296, +1), pvr.octonet (1e44819), pvr.pctv (c20fed1, +3), pvr.stalker (cca5807, +3), pvr.teleboy (0f3ccfd), pvr.vbox (cd73f9e, +1), pvr.vdr.vnsi (6bbdb78, +2), pvr.vuplus(5d70dd2, +19), pvr.wmc (6a95f98, +1), pvr.zattoo (b10004a, +2), vfs.libarchive (eb71453, +2), pvr.sledovanitv.cz


17.8.347, same issue, kodi launches and runs for about 4 seconds and then crashes (sad face) and relaunches in a never ending loop.



Can you try stopping Kodi, rename .kodi to .kodi.bak and restart to see if it fixes the issue.

Failing that please post a debug log. The log above doesn’t have debug enabled.


ok, give me a few minutes and i’ll let you know.


Also you are not on 347 yet.

ii vero3-mediacenter-osmc 17.8-346 armhf Media Center package for OSMC


Yep, just noticed that, probably because I’d rolled back to 17.8.345 and OSMC then updated to 17.8.346 and I assumed it had updated to 17.8.347.

I’ve now updated to 17.8.347 and so far everything seem to be running fine… Sorry for the false alarm :frowning_face:


Great stuff. No problem.
Probably didn’t update to the latest as it takes up to an hour to sync the update mirrors.


That would also explain why

sudo apt-get install vero3-mediacenter-osmc

Tried to install 17.8.346 and I had to manually install the 20181026 deb package.