No.
Thank you. I will try it.
So, just to know, what is used for NFS userland, from Kodi UI ?
libnfs.
ii libnfs12:armhf 3.0.0-2 armhf NFS client library (shared library)
Thank you.
With fstab mounts it works normally.
Thanks for the feedback. There does seem to be a problem for some people with the current Kodi 18 / libnfs set-up. Perhaps it’ll be fixed with Kodi 19.
Hopefully it will be fixed in Kodi 19. A newer version of libnfs would be nice. But is this lib coming from the OS or Kodi ?
It’s from the Debian repository:
osmc@osmc-4k:~$ apt-cache policy libnfs12
libnfs12:
Installed: 3.0.0-2
Candidate: 3.0.0-2
Version table:
*** 3.0.0-2 500
500 http://ftp.debian.org/debian buster/main armhf Packages
100 /var/lib/dpkg/statusSo Kodi 19 won’t change anything about that. It’s up to Debian. Bullseye has the next version, libnfs13 (4.0.0). Maybe a backport is possible ? Or wait for OSMC to be based on bullseye 
.
We can package our own libnfs (we have done so in the past); but recently moved back to the Debian version because the upstream version seemed modern enough.
If there is an issue with the package, it should be reported to Debian upstream.
The issue may actually be related to your Arch system however.
Maybe. But From my Debian computer, I don’t have the problem, the speed is normal. And it has the same libnfs than OSMC
Maybe just a problem with this version of libnfs and the latest kernels. Unfortunately, I don’t have the skills and the time to seach further.
But I believe that libnfs12 only supports nfsv2. And maybe the latest kernels use nfsv3 or v4 only.
libnfs is a userland implementation – so it shouldn’t depend on a specific kernel version.
Here’s the changelog. libnfs/CHANGELOG at master · sahlberg/libnfs · GitHub
We’re on version 3.0.0-2
Reported in Archlinux, will be fixed: FS#69491 : [linux] NFS kernel regression, consider reverting it in our package
1 Like
Thanks for the link, which actually contains a link to a Kodi problem report: Unable to play some media under kernel 5.10.11 when using NFS · Issue #19147 · xbmc/xbmc · GitHub
Seems like it was a kernel regression iintroduced in Linux 5.10.11.
1 Like
Thank you guys for the informations ! Glad they found the problem and a fix is on the way.
I think I’m seeing the same error on my RPI3 with Kernel 4.19.122-2-osmc and libnfs12 3.0.0-2. Video is basically unwatchable as it skips around and reports a bunch of sync errors in the logs. Mounting via standard fstab NFS works just fine, as does playing local files.
Am I running in to the same issue? Or is it something else? Any possibility of downgrading my kernel or libnfs12?
Why not stick with that solution?
I have three sources setup on two Pis. I could do it, but it would be a semi-large rework.
If it were as simple as an apt downgrade or something that would be easier.
I don’t even know if I’m running in to the same issue yet. This issue seems specifically related to the Vero 4k and the 5.1 kernel.
If you want to use a shared mysql database for several Kodi clients that use different methods to access the shared media (e.g. a mix of SMB, NFS and/or fstab based access) you could use the path substitution function of Kodi to align the access. But watch out it is important that you only add new files to the database from a single client otherwise you would need to have different path substitutions on each client.
Please see [HowTo] Repairing File Paths with Path Substitution for details.
Path substitution does not interact with how the file paths are stored in the database as it only stores what is in sources.xml. As such, as long as all clients are using the exact same file file paths (preferably the exact same sources.xml) then one could path sub to a local mount and it would have no impact on how the paths are getting stored in the database, or the ability to update from any client.
All the pain comes when people change the source paths on an existing library which is (almost) never the correct approach.