Kodi stutter using storage VM

[weust]

The Subject maybe a bit weird, so let me explain the situation in detail.

I have a Synology DS415play NAS which hold my MKV files (Pretty much everything is remuxed Blu-rays in my own collection).
Using a Raspberry Pi 3+ with LibreELEC and SMB shares everything runs great, even the 40 to 50Mbit/s files. No stutter or buffering, just good.

I'm setting up a ZFS VM using FreeBSD (actually HardenedBSD, but that is a besides the point here) with datasets shared through NFS and SMB.
Copying files to and from the SMB share goes at nice Gbit/s speed, NFS with about 80MByte/s (still figuring that one out). So those speeds are fine too. Currently it's only a two drive mirror I am testing with.

For some reason LibreELEC starts to buffer about 5 seconds after starting a Blu-ray remux and after that sounds drops and video is unwatchable.

Same behaviour goes if I use a Windows 2016 VM with the same controller but different disks.
CIFS speed is max and playing a video on my Linux laptop using smplayer plays perfectly.

So that leads me to something being wrong with ESXi somewhere. But I can't figure out what and why.

The VM's have 32GB RAM and a modified Dell H310 in passthrough for the disks.
No log or ache disks, thought I had before and that didn't matter at all.
ESXi version is 6.7 on a Dell T320 with a Intel E5-2420 CPU and 96GB RAM, a Dell H710 RAID Controller with a four SSD's (two datastores).

I'm hoping someone has an idea what might happen here as I am about to run out of ideas to test.
The only thing I haven't tested is ZFS or Windows 2016 on bare metal, which I am hoping to avoid as well since I run several other VM's in ESXi as well.

 

[Zedicus]

i had a similar set up a while back and posted a lengthy post on the freenas boards about how to fix this but it was before they allowed any VM talks so it was all deleted. the issue with performance (i was even using the same H310 cards) comes down to freebsd being virtualized not liking accessing the drives across pci pass-through. the fix was to have the hypervisor emulate a real CPU to the freebsd VM and turn off any virtualization accommodations being used on the VM. (so the guest OS believed it was on REAL hardware) this was a fair performance it to the VM so then i aded more VCPUs and VRAM to it to help offset. also the next issue became related to the network that the freebsd VM was using. (at that time i think it was a bad VIRTIO NIC driver and i sorted that problem out by compiling the testing branch of the VIRTIO freesd NIC driver) so that part probably is not an issue any more.

i am all for virtualizing EVERYTHING including the SAN/NAS and passing HBAs and fiber NICS into the VM. but unless you have time to trouble shoot (and odd things will happen anytime anything updates or changes at all) a small direct fiber attached physical SAN/NAS is a good idea.

 

[weust]

I forgot about this topic, tbh.

It turned out to be Kodi, and how it handles NFS (or at least NFS) shares from within Kodi.
That method sucks.

The way that does work properly, although I don't like it, is to create files in certain directories that mount the file share outside of Kodi, so on the OS layer.
Using NFS shares what way works perfectly.

So in the end it had nothing to do with my half-virtualized ZFS server

 

[BlueLineSwinger]

Ugh, yeah. Kodi's built-in NFS and SMB clients are bad. Running on top of full-fledged PC/Mac hardware covers their deficiencies, but they fall apart on the RPi and other low-power platforms. Better to let the OS handle any network shares.

I never understood why Kodi doesn't, where available, simply use the host OS clients.

 

[PigLover]

I've had much better luck with Kodi sharing over SMB than NFS. It is actually pretty good as of Jarvis (no stutter running Kodi on Amazon Fire with SMB shares from a Linux file server).

Of course adding SMB shares to your file server might be just as offensive to you as mounting NFS from the OS...

 

[Zedicus]

KODI, oddly, has an ability to use it's own complete network environment. however, as you found, mostly it is best to ignore that feature and do things through the OS, and attach kodi to those connections.

also my environment is about 80% linux, but i do everything over smb/cifs and i have a virtualized active directory environment for folder permissions. this works well and allows simplicity for the users, (and the very minor performance hit for only using windows shares even across a linux environment is not a big deal.)

 

[weust]

I just wish they would throw out their own network environment.
Although I can understand it when using Kodi on Windows and you want to connect to NFS shares easily (without having to explain a n00b how to install NFS support), having to do it on the OS level to make it actually perform properly, is just wrong too.

They need to make a real choice. Use the OS layer on Linux/*BSD to support SMB/NFS/etc, and don't on Windows unless NFS support is detected.
How hard can that be?
But it probably has the same priority as the external database "support". It's there, but has been experimental for years.
Meaning you dick around in a config file on the OS level instead of setting up in Kodi.