first of all, this is an amazing piece of hardware! Well done Sam!
Quick rundown of my setup:
Vero4k, HDMI to the TV, S/PDIF to the Amplifier.
The amplifier sadly doesnt support DD+/E-AC3 so it needs to be decoded on the vero4k itself.
At this point I stopped playback because the sound and video became very hacky.
I monitored Network (SMB Shares tend to be net I/O heavy) and CPU/Memory but none of them were spiking up.
The CPU was going around 40% (So 10% per core) while playback and the network was smooth at 40-60mbps.
Memory was 50% used (around 1G free)
There’s no other process in the background stealing memory or cpu.
Any pointers on how to get this a bit smoother?
I dont have playback-sync enabled, fyi.
Cheers!
f0o
//EDIT:
The filesize is around 40Gbytes it’s an uncompressed 2160p mkv
To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.
Please ensure that logs are produced with debug mode enabled.
I suspect it may be a buffering issue.
A debug log will help as @yknivag suggests, but it would also be useful to see VQ and AQ levels (press context menu)
Logs will follow in the evening when I can access my TV again
//EDIT:
I switched debug on, rebooted and tried the playback; However with debug on the idle state of kodi is around 50+% cpu and playback wouldnt even go smooth for 2 seconds.
I got the log but it’s spammed with stalls, I’m not sure it’s useful.
Yes – I don’t think Kodi’s buffering enough which is causing the stalls.
I notice that you’re using Samba, which has a bit of protocol overhead, but is generally OK. Did you mount / access the Samba share via Kodi, or did you mount it via /etc/fstab? The latter allows the kernel to perform readahead, which tends to get you more throughput.
This is probably the quickest and easiest way to improve playback. There are ‘advancedsettings.xml’ tweaks that can be used to increase the buffer size; but that’s probably best avoided for now.
Are you able to play a basic 1080p Big Buck Bunny sample clip without any problems? I’d like to know that you are able to play some clips first.
Secondly, when playing the 2160p rip, if you press the three line (context menu) button on the remote and then press OK, you will see the video playback stats. Can you take a screenshot or photo so I can see the VQ and AQ levels? This will let us know if Kodi is indeed struggling with buffer issues.
In theory: you shouldn’t need to adjust those video buffer sizes at all if network throughput is sufficient. There is a detailed explanation of these cache settings here: http://kodi.wiki/view/HOW-TO%3AModify_the_video_cache.
As you seem to be involved in the development of a network monitoring system, I’m not going to ask you to check your network…
Yeah 1080p works just fine, I’ve got some movies that are similar in filesize as this 4k tv series’ episode.
I’ve ramped up the videocache to 836763648 while leaving the bufferfactor at the default and although it didn’t help with the built-in SMB client, the mounted SMB worked out just fine. Very occasional rebuffers where I assume I could just fine-tune the bufferfactor to even out the data-stream to be less bursty.
I reverted my change and here are the stats using the built-in SMB client:
VQ is around 40% occasional drops to 30% on start
AQ is around 50% occasional drops to 30% on start
after a while VQ jumps up to 70-80%
at the same time AQ is steady at 99-98%
VQ is considerably unstable and jumps between 30-70% all the time after a further while.
VQ and AQ drop to < 10% when the shutter starts.
Using native CIFS mount:
VQ is now considerably higher, residing a lot in the 80% mark. Occasional drop to 50-40%.
AQ is solid at 99% all the time
but around the same time as with the SMBClient from Kodi (5 minutes) the VQ drops to <10% eventually ending at 0% for a while. It does max out the 100mbps port it has (can it do Gbit?)
Okay – good to confirm that it is indeed a buffering issue.
The Ethernet is 100Mbps, but what I suspect is happening is the variable bitrate is catching the device out and it’s not buffering ahead enough.
Is SMB a must for you? NFS usually gets better performance if it’s possible to use it
Try:
<cache>
<memorysize>62914560</memorysize> <!-- number of bytes used for buffering streams in memory
When set to 0 the cache will be written to disk instead of RAM -->
<buffermode>1</buffermode>
<readfactor>6.0</readfactor>
</cache>
That will use approx 180M for RAM (3x60M). But the device should have plenty of available memory.
I tried your settings with NFS mounted via fstab, sadly same result. Around 4-5 minutes into the file the NIC is maxed for a short moment and the video stalls.
I also tried increasing it to 1G (3x300M) but same results.
Generally, is More = Better on memory size as long as there’s some memory free for the OS?
And also, if readfactor is super large (9001 for example), would this impact kodi’s performance or will it just keep the NIC busy?
Yeah the OS is fully responsive, even the UI and remote are unaffected.
I’ve let the video stall a bit and now I got the information that Source is too slow for continuous playback… At that time the NIC was doing 30Mbps, it has direct connection to the NFS server (I changed it from SMB now, using fstab as well) on a gigabit network.
Okay – it’s definitely a buffering issue. I’ll look in to it. There have also been some improvements to the Ethernet driver which will land in a kernel update soon.
Do you have 802.11ac WiFi? It’d be interesting if you could disconnect the Ethernet, connect over WiFi and let me know if you still have issues.
