Vero 4K+ gone weird after attempted reinstall of OSMC

After installing a Leia test build on my 4K+ and playing for a while, I decided to go back to the standard Krypton image. To do this, I grabbed the OSMC image creator (for Windows), created an image on a micro-SD card (selecting “Vero 4K”, latest version). I plugged the card into the 4K+ and rebooted.

It went through some sort of installation process and then launched the setup wizard, so I assumed everything was okay. But since then, everything has started lagging like crazy. I’m not sure what’s slow - I think maybe either accessing the network or accessing local storage.

My first thought was “Is this Vero 4K image actually compatible with the Vero 4K+ ?” If not, where do I get a 4K+ image from?

If it’s supposed be compatible, then what should I do to straighten things out?

Did you remove the SD-card?

Yes.

After letting it stew for a while and rebooting, the lag seems to have cleared up for now but it’s still behaving weirdly in other ways - key-presses in SSH bringing up the wrong character on the screen, etc.

What do you mean by this?

I rather think this is the initial scan of medias that causes high load and a little bit of unresponsiveness.

Okay, I’m going to try a fresh reinstall tomorrow morning, and then let it simmer for a while before assessing it. :slight_smile:

Can somebody confirm that the downloadable Vero 4K image is entirely compatible with the Vero 4K+ ?

Yes, it is.

You need to configure your media sources after installations of course. You see the scrapers’ activity on the top right even while playing a video (assuming you’re on OSMC skin).

Make sure you use the August image for the 4K +. Some of the older images will boot but Ethernet and LED will not work properly

Okay, I did another reinstall this morning, starting from scratch. It got so messed up it wouldn’t even boot up. :frowning:

Tried again, from scratch. This time it booted without any complaints. Took out the SD card as soon as the setup wizard appeared on the screen. Went through basic setup, did a manual install of updates.

It’s now doing its sluggish thing again, and I think it may be a network issue. I managed to get it to run iperf3 and these are the rather unimpressive results:

osmc@osmc:~$ iperf3 -c 192.168.1.13
Connecting to host 192.168.1.13, port 5201
[  4] local 192.168.1.175 port 47594 connected to 192.168.1.13 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  95.5 KBytes   782 Kbits/sec    2   1.43 KBytes
[  4]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.43 KBytes
[  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    1   1.43 KBytes
[  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    0   1.43 KBytes
[  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.43 KBytes
[  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.43 KBytes
[  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    1   2.85 KBytes
[  4]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   2.85 KBytes
[  4]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   2.85 KBytes
[  4]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec    0   2.85 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  95.5 KBytes  78.2 Kbits/sec    5             sender
[  4]   0.00-10.00  sec  1.43 KBytes  1.17 Kbits/sec                  receiver

iperf Done.

And, after going away and leaving it for a while, suddenly, magically, things are more or less working again. (sigh)

osmc@osmc:~$ iperf3 -c 192.168.1.13
Connecting to host 192.168.1.13, port 5201
[  4] local 192.168.1.175 port 55317 connected to 192.168.1.13 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   108 MBytes   908 Mbits/sec    0    272 KBytes
[  4]   1.00-2.00   sec   109 MBytes   914 Mbits/sec    0    272 KBytes
[  4]   2.00-3.00   sec   109 MBytes   912 Mbits/sec    1    202 KBytes
[  4]   3.00-4.00   sec   109 MBytes   914 Mbits/sec    1    174 KBytes
[  4]   4.00-5.00   sec   109 MBytes   914 Mbits/sec    0    208 KBytes
[  4]   5.00-6.00   sec   109 MBytes   912 Mbits/sec    0    230 KBytes
[  4]   6.00-7.00   sec   109 MBytes   917 Mbits/sec    0    241 KBytes
[  4]   7.00-8.00   sec   109 MBytes   916 Mbits/sec    1    194 KBytes
[  4]   8.00-9.00   sec   109 MBytes   911 Mbits/sec    2    131 KBytes
[  4]   9.00-10.00  sec   108 MBytes   903 Mbits/sec    1    141 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.06 GBytes   912 Mbits/sec    6             sender
[  4]   0.00-10.00  sec  1.06 GBytes   911 Mbits/sec                  receiver

iperf Done.

I don’t know. :frowning:

So, what is the infrastructure between the Vero and the iperf3 server? What server is it?

The Vero 4K+ is connected to the switch, as are my router (Asus RT-AC86U running Merlin firmware), several other AV devices, and a desktop PC.

At the point when I was having trouble, I got numbers like that using either the desktop PC or the router as an iperf server, and I was seeing similarly bad speeds in both directions (i.e. with and without the -R option).

Running an iperf3 test between the desktop PC and the router showed no problems in either direction, so there’s no issue with either of those devices or with their cables.

I tried several network cables on the Vero and several different ports on the switch, but nothing seemed to help.

Now, as I said, it seems to be magically working again, although I am still getting some retries showing up in iperf.

I’ve already returned one Vero 4K+ with a suspected Ethernet fault. That one was giving me highly erratic TX speeds, which never got above 500Mb/s and sometimes dropped below 10Mb/s. Sam was unable to find anything wrong with it, but sent out a replacement anyway. Up until now the replacement has been working much better - speeds of around 900Mb/s - but all this nonsense today is worrying me.

I’ve got several other devices connected to the same switch, and none of them have any problems at all. Either I’m extremely unlucky or the gigabit Ethernet on the Vero 4K+ is unusually picky about what it needs to be connected to.

Do you by chance have another switch to try it out? That would be my next troubleshooting step.

I have exactly the same issue!

Did exactly the same as you. Went from the crappy Leia build to a fresh august build, and exactly the same network speed issues as you experience. Only thing that works is using WiFi.

I’ll check tonight if the issue is gone for me after a day of running idle…

Hmm. That is odd. Things like this don’t happen when going from one build to another one.
Or - the ethernet-port firmware has been changed and is wrong.
(Just thinking out loud - and I don’t know how to fix it).

Thats what i thought. The new build might have updated something in the network controller firmware.

Can anyone confirm/deny this?

Well, as I said, the extreme slowness has cleared up by itself.

I’m still getting a few retries on iperf, which I shouldn’t really. Out of curiosity, I tried connecting the Vero 4K directly to the PC, directly to the router, and to a different switch.

Connected directly to PC: no retries.
Connected directly to the router, using the same cable that I used when connecting to the PC: retries
Connecting to my usual switch: retries
Connecting to my spare switch: retries
Five other devices connected to my normal switch: no retries for any of them.

So, clearly it is possible for the Vero 4K+ to establish a clean connection sometimes - it works when connected directly to my PC - but it can’t establish a perfect connection to three other switches/routers, despite the fact that four or five other client devices connected to those same switches/routers with the same cables experience no problems at all.

So I’m forced to conclude that the Vero 4K+ is extremely picky about what it connects to. My best guess is that the signal it produces is simply too weak, so most devices lose an occasional packet but something very sensitive and high-powered (e.g. desktop PC Ethernet card) is able to read the signal cleanly.

Note that this latest analysis may not have anything to do with the problem I was originally talking about in this thread (the slow-down that resulted from downgrading from a Leia test to the standard Krypton image). It could be a more general Ethernet problem.

I do have retries when my kids are watching videos from the NAS or streaming from Netflix/Prime at the same time. It is totally normal that sometimes you get a retry. It is an excessive amount of retries that poses problems. Having total of 50 retries would still be Ok. When you get 500 and more, then there is an issue (me thinks).

That looks like the PHY is stalling to me. I did make some changes to the driver in the latest kernel.

No – that’s not the issue.

If no packets are being sent at all, it’s not an over the wire / communication issue. If you can reproduce it, you should run dmesg | paste-log and send me the URL.

If it’s hardware, it will either not work or it will work. With the problematic devices we received, we discovered that the fault won’t be intermittent.

With some logs, I’m sure I can work it out.

Sam