Very 4K hangs sometimes

Sometimes my vero4K stops playing a video, and when that happens, other videos that played fine before stop playing as well.

By ‘stops playing’, I mean the video freezes, and starts buffering. Tonight this happened after 14 minutes; and after that, I couldn’t even play the start of the video (which played fine the first time). Other videos that played fine an hour ago don’t play anymore - the video freezes and buffers forever.

I don’t know if it’s related, but the first time it happened (tonight at least), I noticed a ‘connected to the internet’, as it if had lost connection. Then a ‘downloading updates’ message.

I rebooted the router; turned off my TV and soundbar; but it changed nothing. The vero doesn’t look like it’s overheating.

I checked similar topics, and in one of them there was a similar setup - movies & DB in a Synology NAS. But my SMB service seems to be fine.

Logs are here:

I’d try another ethernet cable or at the very least reseat your connections.

1 Like

A new cable didn’t change anything, unfortunately.

Also, I switched to wireless connection, and now kodi won’t even load the ‘recent movies’. If I ssh to the vero4k, I can ping the NAS with no problem.

Note, I use a MariaDB to store the library data (in case that helps); but again I’ve had zero problem until recent updates.

First investigation, check performance between Vero and NAS with iperf3.
Try to enable SMB MTU Mitigation settings>services>SMB client>mitigate MTU issues with SMBv2

Maybe something changed in the network, we suggest to check your network with iperf3. Please read this howto


Thanks; I will try that. And I will check, but I have installed Kodi on the Xbox and that works fine; and it’s the same setting.

Actually while I was typing this, I was on wireless connection, and my show which was frozen started to play again after 10 minutes. Then I switched back to wired; and then the same thing on reboot - ‘recent movies’ extremely slow to load; playing the same episode led to a freeze, and then after a few minutes, it unfroze like nothing ever happened.

It’s like it’s trying to cache something… and that cache gets flushed once in a while (maybe the last osmc update flushed it)

I spoke too soon - it froze again. I will test with iperf3 :slight_smile:

As you have a Synology NAS the MTU Mitigation is most likely the fix.

1 Like

It looked to me like when you had an issue with playback the system was showing the ethernet connection went down. Is there a different port you could try on the switch it is connected to?

You might also try making sure that both ethernet and wireless is enabled and then shut down the Vero, unplug the ethernet cable, then power cycle to turn it back on with the ethernet cable still unplugged so its only connection is wireless and see if that stays up. When your using a shared database Kodi really doesn’t like it when you switch network connections on the fly.

@darwindesign thanks; I did notice that the connection info was updated on reboot, so I did reboot after every change. But I don’t think it’s the ethernet or wifi connection, at least not directly. Results are identical no matter the type of connection.

I think I managed to solve it: I got rid of my SMB share ( using SMBv2 didn’t help unfortunately); and implemented NFS, and transfer speeds are much quicker - simply listing a folder is at least 10 times quicker. I will test further but now I’m able to play stuff with no issue.

I really appreciate your help in this! I have been using SMB for at least 12 years; I was too lazy to change… you guys gave me the push I needed.

1 Like

I spoke too soon. Same issue with the same video file. CPU usage is at 100%.

In the kodi.log, I see:
2023-08-13 17:44:51.513 T:2904 info : [WHITELIST] Searching the whitelist for: width: 1920, height: 960, fps: 23.976, 3D: false
2023-08-13 17:44:51.516 T:2904 info : Display resolution ADJUST : 1920x1080 @ 23.98 - Full Screen (23) (weight: 0.000)
2023-08-13 17:44:54.499 T:6477 info : CVideoPlayerAudio::Process - stream stalled

After 5 minutes, it unfroze. It might be because of the library update that’s been running for a couple hours… I’ll post updates here when relevant.

Update: I stopped the library scan, but no change. In debug mode, I see in the log:

debug : CVideoPlayerVideo - Stillframe detected, switching to forced 23.976024 fps
2023-08-13 17:56:06.136 T:6682 debug : CVideoPlayerVideo - Stillframe left, switching to normal playback

Here is the OSMC logs:

I see for instance:
info : CAESinkALSA::InitializeHW - Your hardware does not support AE_FMT_FLOAT, trying other formats
2023-08-13 13:16:38.158 T:2948 info : CAESinkALSA::InitializeHW - Using data format AE_FMT_S24NE4

but it’s “info” so I’m not sure it’s an issue.

The fact that I can play some videos with no issue and not others suggests that it’s linked to the video encoding and it’s not linked to the connection or bandwidth (in wired ethernet it should be fine anyway)

2023-08-13 17:58:52.510 T:6678    debug <general>: Readrate 1246000 was too low with 1949688 required

Did you run an iperf?

Well your library update seems to have issues with the SQL Database, maybe it make sense to clean those out first

2023-08-13 13:29:08.291 T:2935    error <general>: SQL: [nicovideos121] Undefined MySQL error: Code (1062)
                                                   Query: insert into actor (actor_id, name, art_urls) values(NULL, 'Tamas Hagyo', '')
2023-08-13 13:29:08.291 T:2935    error <general>: AddActor (Tamas Hagyo) failed

Well the easiest to figure that out is always to play the file locally (USB Stick or emmc) to exclude the network

1 Like

It looks like it is the bandwidth, for some reason. Transferring a file over NFS onto the Vero was about 1.5MB/s . It should be much faster. And while that was happening, playing an SD video was buffering.

I have a mesh router that’s connected to the main router via a MoCa ethernet adapter. Maybe that’s what is causing the issue, something degraded there.

Actually, my mesh router speed should be fine. My phone is connected to that same mesh router and download speeds (on the wifi) are around 200-500Mbps. (25/62MBps). So it might be related to the Synology drive… I’ll dig further.

Well iperf test will tell you

True, I was trying to use it :slight_smile: … I have never used it. While on the vero, which command should I use?
On synology:
iperf -s
bind failed: Address already in use

is there a way to do it from the Vero client?

If you can not bind the address on the NAS you can use iperf -c <IP of Vero> and run on Vero iperf -s. But be aware that iperf and iperf3 might not be able to communicate. If it doesn’t work with the NAS you first can also try Vero to e.g. your PC

You read the howto I refereed to?

iperf3 shows this:
osmc@kylian:~$ iperf3 -c
Connecting to host, port 5201
[ 5] local port 51806 connected to port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 11.4 MBytes 96.0 Mbits/sec 0 419 KBytes
[ 5] 1.00-2.00 sec 11.5 MBytes 96.6 Mbits/sec 0 788 KBytes
[ 5] 2.00-3.00 sec 10.0 MBytes 83.9 Mbits/sec 0 1.08 MBytes
[ 5] 3.00-4.00 sec 17.5 MBytes 147 Mbits/sec 1 1.16 MBytes
[ 5] 4.00-5.00 sec 18.8 MBytes 157 Mbits/sec 0 1.17 MBytes
[ 5] 5.00-6.00 sec 17.5 MBytes 147 Mbits/sec 0 1.18 MBytes
[ 5] 6.00-7.00 sec 17.5 MBytes 147 Mbits/sec 0 1.19 MBytes
[ 5] 7.00-8.00 sec 17.5 MBytes 147 Mbits/sec 0 1.22 MBytes
[ 5] 8.00-9.00 sec 18.8 MBytes 157 Mbits/sec 0 1.26 MBytes
[ 5] 9.00-10.00 sec 18.8 MBytes 157 Mbits/sec 0 1.33 MBytes

[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 159 MBytes 134 Mbits/sec 1 sender
[ 5] 0.00-10.01 sec 156 MBytes 131 Mbits/sec receiver

While not amazing, it should still be fast enough… so it’s something else.

  • Can you describe your network infra structure between the Vero and the Syno, including switches, router, converters, etc.?
  • What Vero is it, 4k or 4k+?
  • What Synology?
  • What component uses what technology (100Mbit, 1Gbit, etc.)?

In your initial post you required 14 minutes until the issue started. The default for iperf3 is just 10 seconds. Use the -t parm on the client side to let it run much longer.