No, if the bitrate is above 100 Mbit/s you would not be able to play the file as buffering only helps for bandwidth fluctuations but not if your bandwidth constantly is below the required level.
If you want to play files with more than 100 Mbit/s bitrate via LAN than you need to either use AC Wifi or a USB gigabit dongle but even in 4k their would be limited files with that requirement.
1 Like
Thereās not a lot of content > 100Mbits. Most that is has a variable bitrate, so you can usually play this content, but it takes a second or two to start.
Sam
I just bought Vero 4k and 50% of UHD 4k contents that i tried was played with lags.
I have NFS fstab synology share.
And increased buffer in advancedsettings
<cache> <buffermode>1</buffermode> <memorysize>536870912</memorysize> <readfactor>1</readfactor> </cache>
I tried different readfactor (1-20 ) but lags always appeared on eth0 consumption at 98 Mbit/s.
After i tried USB3.0->Ethernet 1000T adapter lags gone away.
And average usbnet0 consumption is 105 Mbit/s with 308 Mbit/s in Max.
Vero 4k 2.0 really need gigabit ethernet.
Can you post the MediaInfo of a file youāre playing?
If itās a 4K UHD rip, the ABR will be < 100Mbps.
Our focus is on the smooth playback of 4K BD rips.
We need some improvments to caching and buffering and thatās what weāre working on.
BD spec caps out at 128Mbps (theoretical).
Hello, thank you for replay.
Yes ABR < 100 Mbps.
http://paste.osmc.io/uqonijegex.vhdl
http://paste.osmc.io/itaxerehek.vhdl
I tried different settings for buffer in advancedsettings before.
But canāt get successful result.
After go with gigabit ethernet problems disappeared.
Could you give some advice for the buffer settings?
Have you checked your network with iperf when using the 100M onboard? Are you getting 94M constant throughput?
I checked with nload and at 80% time it was at 98Mbit/s.
So to recap:
- Your network can continously transmit 98 Mbit/s
- You are using fstab based nfs mounts
- The movies that are stuttering having an average bitrate <70Mbit/s
- You already configured a 500M cache settings
So if that is not working than something most be wrong. I suggest
- Configure the buffer settings as below and afterwards post the file
cat ~/.kodi/userdata/advancedsettings.xml | paste-log
Remember before changing the file you need to stop mediacenter
sudo systemctl stop mediacenter
<cache> <buffermode>1</buffermode> <memorysize>524288000</memorysize> <readfactor>6</readfactor> </cache>
And start it afterwards sudo systemctl start mediacenter
- Check if there is any other issue from an NFS perspective. Time the copying of the file from the NAS to the Vero
time cp /mnt/<NAS>/<FILE> ./this would give you the average sustained throughput
So to recap:
Your network can continously transmit 98 Mbit/s
You are using fstab based nfs mounts
The movies that are stuttering having an average bitrate <70Mbit/s
You already configured a 500M cache settings
Yes.
Thank you.
I will test it today at the evening.
Also I still would suggest to validate the throughput with iperf for a duration of 5 minutes would give clearer picture than nload on the real bandwidth available
My ~/.kodi/userdata/advancedsettings.xml
https://paste.osmc.tv/uwitukujep
time cp for 1.9Gb file was
real 2m45.373s
user 0m0.110s
sys 0m14.880s
iperf gives strange results.
osmc@OsmcBox:~$ iperf -c 192.168.1.150 -f K -t 300
------------------------------------------------------------
Client connecting to 192.168.1.150, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.200 port 54634 connected with 192.168.1.150 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-300.0 sec 78028059507015 KBytes 260093583709 KBytes/sec
osmc@OsmcBox:~$ iperf -c 192.168.1.150 -t 10
------------------------------------------------------------
Client connecting to 192.168.1.150, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.200 port 54642 connected with 192.168.1.150 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 115 MBytes 95.9 Mbits/sec
osmc@OsmcBox:~$ iperf -c 192.168.1.150 -t 300 -i 30
------------------------------------------------------------
Client connecting to 192.168.1.150, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.200 port 54644 connected with 192.168.1.150 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-30.0 sec 0.00 (null)s 55960653197305 Bytes/sec
[ 3] 30.0-60.0 sec 0.00 (null)s 2359137345148376 Bytes/sec
[ 3] 60.0-90.0 sec 0.00 (null)s 2359137345148376 Bytes/sec
nload with this advancedsettings
Incoming:
...................................
###################################
################################### Curr: 93.88 MBit/s
################################### Avg: 93.84 MBit/s
################################### Min: 92.96 MBit/s
################################### Max: 93.92 MBit/s
################################### Ttl: 2.93 GByte
Best to use iperf3. The original iperf has quite a few weaknesses. Just remember that you need to run iperf3 at both ends. But realistically, youāre getting 94 Mbps on the interface, which is in line with its expected performance.
IMO, a more useful test is to go back to using your gigabit USB interface and run a few more tests to see if the caching is working correctly.
First, youāll need to attach a USB keyboard to the Vero4K and reboot the box. Once Kodi has restarted, enter Ctrl-Shift-o on the keyboard. At the top of the screen you should see some performance information appear. The amount of data in read-ahead cache is shown after āForward:ā.
Play the video that you were using when you ran nload above and observe the āForward:ā figure. The maximum video read-ahead cache size with your advancedsettings.xml will be 192 MB, unless it is a Quicktime file, when it will probably be 384 MB. Iām interested to know if the size of the read-ahead cache rises and falls progressively or if it suddenly gets reset to zero. Does it ever reach its maximum size (192 MB)?
Then repeat the exercise using the Vero4Kās ethernet interface.
Ok, I think this value and the short iperf result confirms your 94Mbit. You still can try iperf3 (also with the -R switch) to validate but I think this is fine.
The nload result you gave was it when you where playing one of the two files you gave mediainfo from? Or was it just from the time you copied that 1.9G file. It would be interisting to see the nload during one of the two files you gave mediainfo for being played
Unfortunately i do not have keyboard. Could tell me action for this? Its not CodecInfo/PlayerProcessInfo ? Something else?
Yes, its nload for this files (Mummy)
Ok, means all the additional audio streams in the MKV increase the average Bitrate that you have 94 MBit eaten up
I think itās now PlayerDebug when Kodi is in FullScreenVideo mode.
The nload graph might indicate that Kodi is still trying to fill the read-ahead buffer using the spare bandwidth.
It progressively increase to 194MB and than fall to 187.5 and than never (20 min) changed.
vq wanders from 10Mb/s to 25Mb/s.
Very useful. So the read-ahead cache fills up and then stays full. And is this on the gigabit or 100 Mbit interface? (Or both?)
Once the read-ahead cache hits its max size, does the network traffic then slow down? And do you see any significant lags/pauses while the cache is > 0 Mbytes?
Sorry it was wrong experiment( i have 1080p film and run it by mistake )
So at 4k Film:
at 100 interface
vq was at between 83 - 90 Mb/s
And buffer never go above 1MB. A most of time it was less 100 KB
First disappeared the audio.
0MB was rarely and best video lags was on it.
at 1000 interface.
vq was at between 83 - 105 Mb/s
And buffer go to 185MB.
No lags.
I donāt think so.
Thanks. I think this shows that the fileās bitrate is a bit too high for the Vero4Kās 100 Mbit interface and no tweaking of the cache or readfactor can help in this case.