Problems with Gigabit Ethernet on Vero 4K +


Last week, we’ve received some reports about issues with Vero 4K + and the on-board Ethernet; particularly when using it with Gigabit switches. We’ve been taking this seriously and making sure we gather all the necessary information and hardware to address this as promptly as possible.

So far twelve customers seem to be affected. Because of such a small proportion of reports, the most logical explanation is a hardware defect affecting these devices. If this is indeed the case, we will of course be replacing these units.

We’ve been working in to the late hours to solve the problem. It can be tricky when you’re unable to reproduce the problem with any equipment you have yourself. It’s important we get hardware (including switches) from affected customers to reproduce the conditions as closely as possible; so that’s what we’ve been doing.

Today (or rather, yesterday now) I received a device from @Nightcustard. My initial suspicion was a hardware defect from the fact he had purchased three other Veros and could swap their positions without issue. I can confirm after receiving the device today that I can reproduce a problem (on TX side) with his hardware when I plug it in to the same switch I’ve had no issues with.

I’m investigating that further; and he will be sent a confirmed working replacement shortly.

Some users have reported that their issues disappear when they use a different switch. This issue may not be hardware related. @martini2 has posted his switch to us; and we expect to receive it in the next day or two. We’ll then be able to confirm if his switch causes issues for all Vero 4K + devices (indicating a driver problem); or if things are fine (indicating an isolated hardware problem).

@dbmandrake and @grahamh have been testing pre-production samples with me since around May 2018. We found a number of problems with the Ethernet driver; but we were able to resolve these. We did have a limited amount of test equipment however; so it’s possible we’ve hit some quirks. We may have fixed things for us, but not for all equipment. That should shortly be evident upon receipt of the reportedly problematic switch.

While I’ve been waiting for an affected unit and problematic switch to arrive, I’ve been digging in to the driver and have identified a number of issues, that quite frankly, wouldn’t have helped the situation. As such, I’ve been working on a number of improvements and I will make these available for testing as well as outline the changes in detail shortly.

So simply put, it’s possible that we have two issues here. Some users may be affected by a hardware problem; and some users may be experiencing a harsh interaction with their equipment. We will resolve both scenarios if this is indeed the case; and we will know soon enough.

In the interim, we’ve done a couple of things to limit the impact of these issues. As @Nightcustard’s device is noticeably problematic, we’re able to adapt our test suite to detect such issues. This will allow us to identify problematic units before they leave London and this should be ready in the next two days. As we learn more about the situation, we’ll also learn more about any symptoms and refine any changes if necessary. This lets us remove any faulty units out of the supply chain promptly.

Further to this, once we have a set of conformity guidelines, we will forward this to our partners in China so that we have an earlier QA step as a buffer. This will prevent us from shipping what would effectively be DOA units from China in to London and add a further robust and independent QA check.

I’ve made a list of affected users and the information we have received from them so far. If I have forgotten you, I do apologise and let me know via PM with a link to your issues / report. It’s been very chaotic for the last few days. I have done my best to cover everyone from the several threads.

In the coming days, I will be following up with you personally via PM to make sure we achieve the correct resolution for you and you end up with a device that meets the standard you’d expect from OSMC.

We’re taking this seriously, and we will get this fixed.

Thanks for your understanding




It’s been, what, a week since this was first reported? Pretty quick to get a response out there.

If anyone is in Seattle or nearby, and has a potentially troublesome Vero 4K+, feel free to reach out to me - you’re more than welcome to stop by and test your Vero on my setup. I have two 4K+ units and both get ~940Mbit.

Thanks for the comprehensive update Sam - I can’t think of any other supplier who would have made the effort to keep customers informed in such an informative way. Mike


This is why we buy and use OSMC products people.

Out of interest Sam, is there any such test that users can perform at home to determine whether our units are affected by this issue?
The reason I ask is as it’ll only be obvious using certain hardware/switches etc…what might be working fine now might only become apparent as being faulty a year or 2 down the line when changing out switches etc, obviously the 4k+ could be out of warranty by then.


Hi Sam,
thanks for the update!
May you also post a quick guide “for dummies” on tests (and commands) to be executed in order to verify whether the 4K+ unit is potentially faulty?

Without any complexity: if your device is faulty, you won’t be able to use the Ethernet and be able to play content. The link will break too frequently


1 Like

Hi Sam,

thank you for the update! If you think that it would help let me know and I will send you back my infected Vero 4K+ by courier for inspection.

Thanks – I’ll be catching up with the users experiencing a problem once I receive the switch and do some testing (should be tomorrow).


It looks like the switch left Heathrow today, so I should get it tomorrow.
Not long now.

I just received my Vero 4K+ and have indeed issus with the gigabit connection.
The Vero is connected on a tp-sg2008 from TP-Link. I don’t see anything strange on the switch side,

Hello, Sam, et al. I took delivery of my 4K+ today (27/9, order number #19782). I think I may have this issue, although I’m not familiar enough with OSMC to be certain I’m not doing something stupid. :slight_smile:

I find it works fine for low bit-rate videos, but a high bit-rate 1080p blu-ray rip sometimes staggers a bit, and a 4K blu ray rip doesn’t play smoothly at all - it keeps stopping to buffer, or just drops frames.

If I hit the menu button on the remote and then press OK to bring up player stats, there’s a number labelled “Forward” which I guess is the amount of video data it has read ahead and cached. When the bit-rate is high, that number starts going down; and when it hits zero, the video starts dropping frames.

If that’s working the way I think it is, then the rate at which it can pull data across the network seems to be something like 20-50Mb/s.

To check that isn’t a general issue with the network or the server, I tried switching to WiFi, and it seems to be much smoother using WiFi than using wired Ethernet.

Is there anything you’d like to know about my setup, anything you’d like me to test…?

Did you run the iperf3 test?



It doesn’t quite work like that re buffering – are you able to run an iperf3 test?

Hi Sam, I was going to return that remote we were talking about but I think Im having some more issues. I was using SMB but it was disconnecting by itself or couldnt find my NAS. I think Ive read all of the forums but nothing worked so I started using FTP which seems to be more stable. Anyway I have choppy playback using h265 files. Audio seems fine but picture is either choppy or one frame loads and thats it. My NAS is Synology DS218 and I use tp link TL-WDR3600 as a switch.

Im trying to use iperf but it doesnt work. is osmc and im connecting via putty from my PC. This is the usual output:
osmc@osmc:~$ iperf3 -R -c
connect failed: Connection refused

sometimes iperf doesnt do anything, just makes another line in command line and stalls

Ping works:
PING ( 56 data bytes
64 bytes from seq=0 ttl=64 time=0.323 ms
64 bytes from seq=1 ttl=64 time=0.288 ms
64 bytes from seq=2 ttl=64 time=0.249 ms
64 bytes from seq=3 ttl=64 time=0.411 ms
64 bytes from seq=4 ttl=64 time=0.146 ms
64 bytes from seq=5 ttl=64 time=0.427 ms


Not sure what to do next.

Did you run iperf on your PC? It will not connect if you don’t run it on your PC as well

Ping looks fine.

After 10-15 minutes of Googling to find out what iperf3 is and how you use it, yes. :stuck_out_tongue:

The numbers bounce around a lot.

Connecting to host, port 5201
[  4] local port 50892 connected to port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  15.9 MBytes   133 Mbits/sec   14   17.1 KBytes
[  4]   1.00-2.00   sec  14.0 MBytes   117 Mbits/sec   17   28.5 KBytes
[  4]   2.00-3.00   sec  12.0 MBytes   101 Mbits/sec   17   9.98 KBytes
[  4]   3.00-4.00   sec  5.59 MBytes  46.9 Mbits/sec   17   5.70 KBytes
[  4]   4.00-5.00   sec  25.4 MBytes   213 Mbits/sec    9   28.5 KBytes
[  4]   5.00-6.00   sec  9.95 MBytes  83.5 Mbits/sec   17   20.0 KBytes
[  4]   6.00-7.00   sec  13.4 MBytes   113 Mbits/sec   13   9.98 KBytes
[  4]   7.00-8.00   sec  8.26 MBytes  69.3 Mbits/sec   12   9.98 KBytes
[  4]   8.00-9.00   sec  8.30 MBytes  69.4 Mbits/sec   14   15.7 KBytes
[  4]   9.00-10.00  sec  6.06 MBytes  50.9 Mbits/sec   13   8.55 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   119 MBytes  99.7 Mbits/sec  143             sender
[  4]   0.00-10.00  sec   118 MBytes  98.7 Mbits/sec                  receiver

I get different readings each time I run it. On one run there was a bandwidth figure as low as 18.1Mbits/s.

Which direction was iperf3 run in?

As you hit 213Mbps, this suggests a networking issue in your environment rather than a Vero issue based on the affected units we’ve studied.

Do you have another device to test with, i.e another PC etc? I ask because the current failure rate for Ethernet based on units received by customers is very low.


Ok, my bad. I wasnt running cmd in Admin mode. My results are good, vero runs almost 1gbps speed so all is ok, false alarm. But it seems that i get almost 100% CPU load on all cores and thats what causes low fps. Ive read Player capable of playing 4k 10 bit H265 media (anime in particular) that vero 4k is too weak for most anime releases. Should I start a thread about that or there is no fix?

The problem with anime is most of it seems to be strangely encoded, so the hardware decoder in the 4K can’t handle it. If it’s only anime that you are having a problem with, you should open a new topic. And make sure when you do that you include mediainfo on the problem file.