YouTube playback - random blank video with 'input not supported' monitor message


The ‘input not supported’ issue just reoccurred (maybe of note, this was immediately after bringing the vero out of Suspend and beginning h265 playback, albeit with the external hdd powered on this time)

osmc@Osmc_Vero_4K:~$ cat /sys/class/amhdmitx/amhdmitx0/configcur_VIC: 16
VIC: 16 1920x1080p60hz
Colour depth: 10-bit
Colourspace: YUV444
Colour range: limited
YCC colour range: limited
PLL clock: 0xc000027b, Vid clock div 0x000b0000
audio config: on
3D config: off

Same command immediately after reboot, playing back the same file (without the input error)

osmc@Osmc_Vero_4K:~$ cat /sys/class/amhdmitx/amhdmitx0/configcur_VIC: 16
VIC: 16 1920x1080p60hz
Colour depth: 8-bit
Colourspace: YUV444
Colour range: limited
YCC colour range: limited
PLL clock: 0xc000027b, Vid clock div 0x000a339c
audio config: on
3D config: off

Notably the colour depth is reported as 8 bit (10bit when in error state), and Vid clock div is different

Spot on, thanks!

1 Like

@retroresolution Can you try the latest update?

For your memory:

  1. Login via the command line
  2. Edit the file /etc/apt/sources.list
  3. Add the following line: deb stretch-devel main
  4. Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
  5. Your system should have have received the update.

I also recommend you edit /etc/apt/sources.list again and remove the line that you added after updating. This will return you to the normal update channel.



Thanks @sam_nazarko , @grahamh

I’ve performed the update.

For the record, uname -a returns:

Linux Osmc_Vero_4K 3.14.29-132-osmc #1 SMP Mon Nov 26 00:05:01 UTC 2018 aarch64 GNU/Linux

I’ll let you know how I fare with this version.

Many thanks.

That’s the latest and greatest.

1 Like

Hi Sam,

Firstly, let me wish you a Merry Christmas, and thank you for all your support this year (both Vero4K and otherwise related).

Nothing urgent, just thought you’d like to know I’ve been experiencing stuttering on 720 and 1080p playback of files on both encrypted and unencrypted partitions.

As is normal, here’s chapter and verse…

I’ve not been using the Vero that much recently in the usual manner (directly playing files from a locally connected usb hdd, and a locally connected monitor), plus illness has left me ambivalent regarding consuming tv shows and films.

I recently installed Samba on the Vero, and had been using a Raspberry Pi 2 with an ALFA Network AWUS051NH V2 (Version 2) 2.4/ 5GHz Dual Band USB WiFi unit, with Detachable RP-SMA Antenna and Ralink RT3572 Chipset as the playback device.

I experienced frequent pauses / freezes, which may, or may not, be due to wifi issues (using 2.4ghz as I’ve at the time I had Kodi 17.3 installed, and was unable to switch to 5ghz. I’ve since installed the latest Osmc on the Pi 2, but performed no further testing, as I started experiencing random, severe stuttering on local playback for short periods on a range of x264 files. Some media seems bullet proof, others randomly falters.

As the drive holding the media is relatively new, and encrypted at partition level, I spent several days eliminating hardware failure (my drives are all mirrored, with identical hardware), via a full low level drive scan, and a full bitwise comparison of the files on primary and backup disks.

Tonight I was watching h265 media from an unencrypted drive, from a different manufacturer, and saw the exact same issue (albeit after several hours of flawless playback).

Top showed no unexpectedly high CPU usage.

I’m wondering if Samba could have caused this, even when no external sources are accessing Vero’s shares.

Should I update to the latest build (currently I’m using
Linux Osmc_Vero_4K 3.14.29-132-osmc #1 SMP Mon Nov 26 00:05:01 UTC 2018 aarch64 GNU/Linux)?

Merry Christmas,

All the best

Hi RR,

Good to hear from you
This might be one we need to pick apart as two different issues, as it seems you have issues with Raspberry Pi too.

If you can, I’d run some iperf or speed tests to check the network.
When you say you can’t connect to 5Ghz, can you elaborate?

You may need to use separate SSIDs, as Vero will pick the strongest signal (as per 802.11 spec); but 5Ghz may have a weaker signal but higher throughput.

Re. playback issue from USB: can you reproduce this; or is it rare?



Hi Sam,

Thanks for the reply, good to hear from you too.

I’m not concerned with the wifi issues - I’m confident that I can resolve all of these once the core system is achieving smooth playback once again, especially now I’ve ditched the custom Kodi-installed-on-Raspbian build, with manually implemented wifi, for a clean new Osmc image. For the record, the source media is from the same hard drives as used for local playback - just streamed.

Unfortunately the local usb hdd playback stuttering is only semi-reproducible, a.k.a the worst type of problem for any developer.

The system has exhibited the problem with the same drives on more than one occassion, and there are entire seasons of specific shows which seem immune, whereas others are prone to the issue.

I’ve not found a method to reproduce the stuttering, even using the same file. Time appears to be a factor, given that the system generally appears stable for several hours before the problem arises. Whilst it’s suggestive of a memory leak (my cheap Samsung tablet does this constantly with YouTube), nothing in Top suggested this was the case, however I did only investigate with bmon, Top, etc, when investigating the issue on wifi.

I could install dstat, however I’m warying of adding further variables into the mix.

Many thanks,

When you get a stutter, you could try uploading logs quickly as it may reveal something


Hi Sam,

Hoping you’ve had a wonderful Christmas Day, if that’s your thing (otherwise, just a great day in general).

I’ve uploaded logs to:

This is immediately after a c. 5 second stutter upon resuming from a brief pause (then skipping back using the left remote key a couple of times) on a 45 minute tv show.

Format is x264
Setup: usb attached hard drive, partition encrypted. All hardware connections are local (vero to hdmi monitor. Hdd to vero usb).

Please don’t even consider investigation until after the holidays!

Best regards,

Forgot to defrost…

Readrate 1450000 is too low with 1480125 required

It looks like there’s a lack of throughput here.
Forget if I asked, but is CPU use high because of real-time decryption?


1 Like

Hi Sam,

I’d say it’s unlikely. Top never shows veracrypt using much CPU, and I’ve been using encrypted files on multiple drives for months (all ntfs).
Top shows veracrypyt (2 processes) using 0.0% / 0.0% cpu and 0.0 / 0.1% ram during playback

The files I’ve noticed the stuttering on recently are both x264 and h265, and low bandwidth compared to some movies I’ve got.

The final nail in that coffin is that it happened on a totally standard unencrypted drive (which finally prompted me to post about it).

Kodi is using between 22 and 35% cpu, and 22MB ram, during playback.

(All above info taken during playback ofx264 media file from veracrypted partition, from one of the series apparently prone to stuttering).

Forgot to defrost? Your Christmas Turkey (or equivalent)? Nightmare.

Dstat during playback:

~$ dstat
You did not select any stats, using -cdngy by default.
Terminal width too small, trimming output.
----total-cpu-usage---- -dsk/total- -net/total- ---paging-->
usr sys idl wai hiq siq| read  writ| recv  send|  in   out >
  3   2  95   0   0   0| 248k 1623k|   0     0 |   0   634B>
  7   4  89   0   0   0|1152k    0 | 276B  772B|   0     0 >
  6   5  89   0   0   0|1408k    0 | 390B  480B|   0     0 >
  6   6  89   0   0   0|1024k    0 |  66B  146B|   0     0 >
  6   7  87   0   0   0|1280k    0 | 210B  406B|   0     0 >
  9   7  83   0   0   0|1280k  192k|  66B  146B|   0     0 >
  9   6  84   0   0   0| 768k    0 | 132B  432B|   0     0 >
  9   6  85   0   0   0| 896k    0 |  66B  146B|   0     0 >
 10   6  84   0   0   0|1152k    0 | 132B  416B|   0     0 >
  9   8  83   0   0   0|1152k    0 | 210B  374B|   0     0 >
  9  12  79   0   0   0|1152k    0 | 132B  416B|   0     0 >
  5   4  90   0   0   0|1024k    0 | 132B  244B|   0     0 >
  5   7  88   0   0   0|1152k    0 |  66B  146B|   0     0 >
  6   5  89   0   0   0|1152k    0 |  66B  130B|   0     0 >
  5   5  90   0   0   0|1152k    0 |  66B  130B|   0     0 >
 12   8  81   0   0   0|1152k    0 |  66B  130B|   0     0 >
  7   3  90   0   0   0|1280k    0 | 132B  416B|   0     0 >
  9   2  89   0   0   0|1152k    0 |  66B  130B|   0     0 >
  8   3  89   0   0   0|1024k    0 | 132B  416B|   0     0 >

Screengrab of Top during above tests

Hi Sam,

Another set of logs.

Same setup as detailed in post, above.

Stuttering begun less than a minute into playback from beginning of episode.


The stuttering is over too quickly to obtain any readings from Top or Dstat, unfortunately.


Do you have A2DP installed?

Running sudo apt-get remove --purge pulseaudio might help…


I was able to replicate the issue at the exact same point, but wasn’t expecting to, so didnt have an ssh session up. Of course it wouldn’t replicate a third time.

Yes, i installed a2dp for bluetooth a few weeks back, but not using it and completely forgot about it… hope your debugging sense is on the money!

Purging now.

I’ve removed the pairing which existed to my Anker Soundcore 2, and disabled Bluetooth, both via My OSMC, and rebooted for good measure.

In case it’s of any use, the thread where I got bluetooth audio working (partly via command line) is here:

My memory is so bad now, I forgot not only all about the work involved in setting it up, but that I had A2DP
installed at all.

I’ll report back with findings…

1 Like

Seems your debugging skills are razor sharp as always @sam_nazarko; so far I’ve seen no issues since removing A2DP, which has also resolved a few gremlins which must have been related:

  • slight pauses when pressing the (i) button during playback
  • a few seconds of audio only, followed by overcranked playback until the video synched
  • youtube playing with no audio for c. 20 seconds when skipping ahead, or resuming)

Many thanks for your excellent work; wishing you a great 2019.

Hi RR,

Good stuff. A2DP is still very rough around the edges; and I do apologise for not noticing this before in your logs.

It should also please you (and @dastrix) to know that the range limiting option you requested will also be in the next update which should land tomorrow thanks to some excellent work by @grahamh.

Have a good 2019 yourself; I hope you are on the mend.



1 Like