Major problems with the March update

Hardly know where to start. The update completed ok, I then went straight to a series of VC-1 mkv files as these have tripped up OSMC updates before now, and I was hoping this update would fix the corruption issue with 1080/59.94 VC-1 that seems unique to the Vero (the Pi is fine, I posted about this previoulsy with a log).

Anway, what I’m getting is a black screen when attempting to initiate playback of material that’s been played many times before, and the system is completely unresponsive.

Also, the context menu button on the remote is no longer bringing up the playback stats play info, it’s going straight into video settings.

I need to rush back to the previous version as the March build is pretty unusable for me.

You can downgrade by reinstalling an older version from the downloads page.

Without logs, it’s hard to help with the issues you are experiencing.

We have changed the remote keymap layout as outlined on the blog

We haven’t made any changes to VC1 playback in this update.


After an additional reboot the Vero became usable again.

How can the keymap for the remote be reverted to what it was? The function of the button above the stop button has changed, and I’d like to switch it back.

FYI. the VC-1 corruption issue mentioned in a previous PM with a link to a sample is still present in the March build. Seems to be restricted to 1080/59.94. This is not a new issue.

The keymap changes are explained in the blog.

As mentioned, we haven’t made any changes for VC-1, so we wouldn’t expect improvement in this area. The kernel is now EOL.

I tried disabling the custom keymap in the input settings and on rebooting, the Vero just stuck at a black screen. I power-cycled and it started properly. However, the OSMC remote is very flaky in use and I am getting a lot “black screen events”, where nothing seems to happen for a while.

I think from your reply you’re saying that you can’t fix the VC-1 issue I raised previously, at least the Pi doesn’t have that issue.

Will drop down to the January build and see how others get on.

No - that’s not what I said.

This sounds like a stability issue here as others haven’t reported issues, at least yet, so I’d suggest a reinstall


What your referring to is playerproccessinfo and it has moved to long-press info (I button) in the new custom keymap.

I’m struggling to think of a way the remotes update could impact stability or cause whatever “black screen events” is. If you think there’s a connection, and have the ability to control Kodi with another remote or keyboard you could unplug the dongle to test to see if the problem persists.

Let me clarify the “black screen events”. Since applying the March update, the Vero is now sometimes booting or rebooting to a blank screen and I have to powercycle. Also, when initiating playbak of an mkv file that has played many times before, either playback starts and when I try to stop playback the screen goes blank and the Vero becomes completely unresponsive, or initiating playback fails immediately and the screen goes blank and the system becomes completely unresponsive.

I am trying to figure out a way of enabling logging and capturing it so I can post, but even that is an enormous headache at present, as the March update has made the Vero so unusable.

We understand that you are experiencing some issues but please, understand that if these issues were a problem with the update at large, there would be dozens if not hundreds of reports. As of now, there is just your report of such issues. We are here to help and are sure we’re going to be able to give relevant support.

Can you explain better why it’s so difficult to enable and capture a log? Maybe we can make some improvement or offer a tip to make this easier?

Even starting the Vero at present is challenge. I have just been able to boot it, enable logging, the Vero appeared to work when starting/stopping playback on a couple of titles, then it just died with a black screen. As I type this I have no way of getting to the GUI to ask it to submit a log.

Can anyone advise how to proceed?

It might be easier for you to just downgrade via If the issue is widespread as you say then it should be picked up by others pretty easily.

It’s worth attempting a reinstallation anyway.

I can do this but installing a production release shouldn’t be such a risky proposition. The Vero in question is also my TVH server, so getting up and running again will take a while.

A very recent thread Vero4K+, after idle, blank screen and no response (have to reboot via ssh or power cord) - #21 by BobLovesOrangeJuice had a similar issue. In that case, disabling HPD lock resolved the problem.

1 Like

I agree – which is why we wanted to get logs to work out what’s happened.
We haven’t had other reports of this being a widespread issue, which suggests that the issue may not lie with the update.

Although Kodi is stuck at a blank screen, I can ssh into the Vero, does this help?

It’s not a debug log so hard to tell.

Do you see a picture if you do:

systemctl stop mediacenter
mv ~/.kodi ~/.kodi-backup
systemctl start mediacenter


I was away from the TV a while and the Kodi screen had come back by itself. I initiated a couple of playback attempts, all seemed well, then I got another blank screen and no response. I used the ssh commands advised, and the screen came back. I can try to rebuild from here to see if the Vero is now stable.

nope. lost responsiveness again, unplugged, then Vero booted to a blank screen.

Some fresh logs would help.

If you bypass the Marantz, do you still lose picture?

Interestingly, you have a lot of HDMI changes in your logs:

Mar 25 15:44:28 osmc kernel: hdmitx: edid: not find mapped vic
Mar 25 15:44:28 osmc kernel: hdmitx: video: auto - get current mode: null vmode_e 67
Mar 25 15:44:28 osmc kernel: hdmitx: stream colourdepth was 8 in para 0x01d83508 (1920x1080p60hz)
Mar 25 15:44:28 osmc kernel: hdmitx: display colourdepth was 10 in cur_param 0x01d80a08 (VIC: 16)
Mar 25 15:44:28 osmc kernel: hdmitx: update physcial size: 16 9
Mar 25 15:44:28 osmc kernel: hdmitx: video: null not valid hdmi mode
Mar 25 15:44:28 osmc kernel: fb: osd current vmode=null, cmd: 0x10000
Mar 25 15:44:28 osmc kernel: hdmitx: set frac_rate_policy as 0
Mar 25 15:44:28 osmc kernel: vout_serve: vmode set to 1080p50hz
Mar 25 15:44:28 osmc kernel: vout_serve: disable HDMI PHY as soon as possible

So yes, the HDMI TMDS clock is being disabled. The question is – why?