VERO4K - 4K DD+ Playback problems (mainly sound)


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.

09:48:13.978 T:3218199536  NOTICE: Creating InputStream
09:48:15.050 T:3218199536  NOTICE: Creating Demuxer
09:48:15.174 T:3218199536  NOTICE: Opening stream: 0 source: 256
09:48:15.175 T:3218199536  NOTICE: Creating video codec with codec id: 28
09:48:15.183 T:3218199536   ERROR: Unable to load, reason: cannot open shared object file: No such file or directory
09:48:15.183 T:3218199536 WARNING: CAMLCodec::CAMLCodec not found, trying instead
09:48:15.187 T:3218199536  NOTICE: Creating video thread
09:48:15.188 T:3260019696  NOTICE: running thread: video_thread
09:48:15.188 T:3218199536  NOTICE: Opening stream: 1 source: 256
09:48:15.188 T:3218199536  NOTICE: Finding audio codec for: 86057
09:48:15.189 T:3218199536  NOTICE: Creating audio thread
09:48:15.190 T:3839882224  NOTICE: running thread: CVideoPlayerAudio::Process()
09:48:15.190 T:3218199536  NOTICE: Opening stream: 2 source: 256
09:48:15.201 T:3839882224  NOTICE: Creating audio stream (codec id: 86057, channels: 6, sample rate: 48000, no pass-through)
09:48:15.417 T:4081054704  NOTICE: CAEEncoderFFmpeg::Initialize - AC3 encoder ready
09:48:15.520 T:3260019696  NOTICE: CAMLCodec::OpenDecoder - using V4L2 pts format: 64Bit
09:52:45.330 T:3839882224  NOTICE: Previous line repeats 3 times.
09:52:45.330 T:3839882224  NOTICE: CVideoPlayerAudio::Process - stream stalled
09:54:29.881 T:3839882224  NOTICE: Previous line repeats 1 times.
09:54:29.881 T:3839882224  NOTICE: CVideoPlayerAudio::Process - stream stalled

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.


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.

It would also be good if we could find out more about the file you are having issues playing. Please see the mediainfo section in How to submit a useful support request - General - OSMC

Thanks for your understanding. We hope that we can help you get up and running again shortly.

Hi @f0o

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)




Thanks for the quick replies;

I’ll get the info over the day (Mrs wants to watch some series marathon, hard to get my hands on it now :wink:

But here’s the mediainfo output:

Logs will follow in the evening when I can access my TV again :wink:

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.

I’ve only redacted the paths and filenames

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.


I’ve it mounted via Kodi.

I used to have NFS in fstab instead but that didn’t run as smoothly as SMB on my rpi2.
I’ll test with putting SMB and NFS in the fstab.

Any way I can spare a library rewrite/loss? Since the paths will be differing when I mount it in fstab…

I think you can use substitution as mentioned on Kodi wiki but for now it’s best to confirm whether it helps or not


Hi Sam,

sorry for the late reply, I didnt had time to play with the vero until now.

I’ve mounted the CIFS via CLI, and used the Video-Files menu to browse to the file in question.

It does have a slight improvement, I’d say about 1-2 sec further in playback before it starts to stall.

Should I increase the video buffer sizes in the advancedsettings.xml? If so, do you have some safe values at hand?

Thanks for your support :slight_smile:

//EDIT: Shoot! it’s easter! Happy Easter! (if you celebrate it, if not, disregard)

Hi @f0o

Happy Easter to you too.

Some things I’d like to check:

  • 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:

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…



Hi Sam,

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


  <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 -->

That will use approx 180M for RAM (3x60M). But the device should have plenty of available memory.

Hi Sam,

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?

Is the system still responsive when video stalls?

Can you run dmesg | paste-log and post the URL?

I believe it will just keep the NIC busy; and as long as free -m shows a reasonable amount of free memory, you shouldn’t have any issues.


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.


Just tried the wifi, although it’s about 1m away from the 5GHz AP I can’t seem to get any decent throughput with it. It’s <20mbps :disappointed:

//EDIT: Rebooted the vero, and got around 40mbps. Still far lower than using wired. And video stalls within seconds :disappointed:

Switched back to Wired now.

I’m still using your advancedsettings recommendation

Ironically being too close to the router can give issues as well :rolling_eyes:

I’ll improve buffering in a near future update and let you know when I have some thing ready for testing.



1 Like

Yeah I know, sadly it’s all nicely tucked into the living room’s TV bench :confused:

I highly appreciate your help and effort, big thank you :slight_smile:

Let me know if I can do anything, change anything, test anything.

if you’re on IRC you can find me on the same nick :slight_smile:

1 Like