Buffering issues

No, first one on 192.168.0.100 has a CIFS / Samba share. Second one is a different server, having an NFS share.

Or are you suggesting that I could mount different servers in the same path, so the /mnt/share or whatever ends up being the accumulative result of all the shares?

edit for example:
smb://192.168.0.100/share mounted as /mnt/share
nfs://192.168.0.101/share ALSO mounted as /mnt/share
?

No different servers (with different data) should be mounted in two different folders.
Just remove your original smb://source from Kodi/OSMC and you are done.

Yes, sorry, I over simplified in the examples.

I now have an /etc/auto.nfs.shares :
/mnt/synoserver/share 192.168.0.101:/volume1/Share

and a Samba share: /etc/auto.smb.shares :
/mnt/xavier-pc/share -fstype=cifs,ro,username=media,password=media,vers=3.0,iocharset=utf8,uid=osmc,gid=osmc ://192.168.0.100/share/

What I wasn’t sure of was the name given to those mounts within Kodi/OSMC. After going into the “browse filesystem” and nagivating to those mount points, Kodi/OSMC still asks for a name for the share and I wondered why as it seems to serve no purpose. And whether THAT name could be the same or whether it also has to be different / unique to each mounted share.

Hi,

Each share should have a different name.

Thanks Tom.

You could, I think, have a single Kodi video source pointing to /mnt, which could search recursively through both mounted folders. (If you really want to).

The reason why you have a separate name for the Kodi source is just so you can call it something descriptive. You need separate sources for movies and TV shows, for example, so you might want to have a Kodi source called “TV” (or whatever) even if the folder name is something else.

And not all Kodi sources are based on folders - they might be based on a DLNA server, for example

In the file manager those are basically just shortcuts and that is why it asks for a name if you go to add one. This part of Kodi is seperate from the rest of Kodi. As for your library, which is the part you set in Videos, they ask for a name as you are setting up sources. You can have more than one file path in a source. What they are named doesn’t matter.

That being said you should understand exactly what you want to do. If you setup new sources for you library and leave the old ones then all your content will be duplicated. If you change your current shares to the local paths your content will be duplicated. If you want to make it so your library uses the system mounts instead you must either dump your existing library and scrape new or alternatively leave your sources exactly as they were and use path substitution to seamlessly redirect the paths in the background…

That is just a descriptive name on what is displayed. It’s up to you what you enter there you could either use /mnt/synoserver/share if you like that or you could write Syno Share

Thanks @sam_nazarko and @fzinken, I watched a 4k UHD film last night and had no issues. Looks like the OS mount works. I still don’t know why it was dropping out before when I had mounted via fstab, but I prefer the autofs solution as I have a few servers I could map, but they’re not always on 24/7. I’ve bookmarked this thread and the autofs how-to for future reference :slight_smile:

Am I right to guess mounting can not made to work if the library is shared between multiple clients (MariaDB, hanewin NFS server)?

That is not an issue. Hanewin doesn’t factor in, and with the MySQL db you can either switch all clients and redo your library (assuming that is an option) or alternatively you can just do a path substitution on any machine you want to setup that way which works with your existing setup. If you check out the howto I linked to a couple posts up it should make this clear how it works.

I don’t see why you think that is easy:

  1. Let’s say osmc puts it into the DB with /mnt/moviesH/…
  2. How will that match up with another kodi on Windows for example mapped H:\movies…

How do you suggest getting the same content on the same path on different clients as they currently are with kodi speaking NFS e.g. nfs:/192.168.1.1/moviesH/…

https://kodi.wiki/view/Path_substitution

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.

Did you read the howto I wrote? This is all covered. Path substitution is a Kodi thing and it works on all versions of Kodi. As such you have the option to either maintain a DB with a universal path that works across all clients and then add a path sub on the Vero to redirect to a system mount, or else do whatever and then fix it on every machine with a path sub. The only really important part is that every client should be running the exact same Kodi sources.

As long as all clients use the same sources in Kodi it can be updated from any machine. Kodi stores absolute paths based on what is in sources.xml and the path sub never factors in.

Sounds hairy, but might try it, then the client adding the files better be osmc running an update maybe every hour…

It really isn’t. You have an existing install that works. If you make a system mount and then add a path sub, and change nothing else, and it just works as your already using it just with a bit more performance.

As many mounts and substitutions as many clients. So not just works as before. But gotta admit uhd movies do buffer and lag.

Is the system still going to add the new movies with the original format, so substitutions keep working going forward?

I cover this in the guide. You don’t change your source, and in turn the DB does not change how the file paths are stored. All you are doing with this kind of path subs is redirecting where it opens the file, nothing more. Literally everything else is the same. Your just telling Kodi essentially when it goes to read from path x, read from path y instead. If your sources.xml is pointing to path x, then the database will store path x. If you remove the path sub then that machine goes back to reading from path x.

:+1: Thanks, will try!

Got to the point of autofs mount working, tester the performance cp to /dev/null is 65-85MBytes/s should be enough for everyone. For the record my home network at the testing:

  1. Client OSMC Vero 4K+ (AMLogic S905D Quad Core 1.6GHz 64-bit ARMv4 aarch64 SoC, 2GB DDR3 Memory, Realtek RTL8211F Gigabit Ethernet)
  2. Linux software bridge fitlet mini-PC (AMD A10 Micro-6700T APU, 8GB RAM, 2xIntel I211 Gigabit Network Connection)
  3. NetGear R7000 router (Broadcom BCM4709A0 @1 GHz, 2xARM Cortex A9, 256 MiB RAM)
  4. NUC 7i7 Windows 10 “server” Hanewin NFSd, single WD120EFAX 5400 RPM SATA disk in a Thunderbolt3 external enclosure
    Without any mount-option or similar tuning :sweat_smile:

Hi, I ended up adding a single generic substitution:

    <pathsubstitution>
            <substitute>
                    <from>nfs://192.168.0.6/</from>
                    <to>/mnt/</to>
            </substitute>
    </pathsubstitution>

It has indeed sped up the initial analysis of the 44GB, 620 file BDMV from tens of seconds until the “play main title” selection apperars down to a couple of seconds, thanks! Now gotta go back and implement other substitutions on the other clients. :slight_smile:
(I am not allowed more than 3 replies, so adding the updates in an edit)

I am not a person to leave optimization opportunities on the table, so I have read up on NFS options:
worth documenting here for fellow users of the Hanewin NFS Server the server side default of max. 8k rsize and wsize read and write windows is a limiting factor. After raising it to 32768 it did help performance:

$ ll Terminator.Dark.Fate.2019.2160p.mkv
-rw-r–r-- 1 osmc osmc 32073967827 Jan 17 22:54 Terminator.Dark.Fate.2019.2160p.mkv
$ time cp Terminator.Dark.Fate.2019.2160p.mkv /dev/null
real 5m46.194s

Meaning 32,073,967,827byte / 346.194 = 92,647,382.18166693 → 92MByte/s
I think it is close enough to the theoretical bandwidth, especially considering that I have two hops in my network between server and client (although the router hop may perfrom Switching in ASIC).

I did try to increase it to 1048576 based on Consistently interrupted playback - #11 by THEM , but that only seems to work for Linux.
Hanewin NFS Server maxes out at 65536, maybe because it does not support NFSv4.
NFSv2 is limited to 8k and NFSv3 to 64k and according to 5. Optimizing NFS Performance - maybe old docs from the linux 2.4/2.5 times.
Oracle say NFSv3 should already be unlimited: File Transfer Size Negotiation - Managing Network File Systems in Oracle® Solaris 11.2
IBM also says they do max 512KB on both NFSv3 and NFSv4: NFS read (rsize) and write (wsize) limit
(another update by edit for not being able to post a reply)

Increasing the Hanewin NFS Server rsize / wsize to 64k did help a bit further: 100,089,776.5 bytes/sec! Note: this file is on another external 5400 RPM SATA drive that is connected by USB3 instead of TB3. Bottomline USB3 external drives can still almost saturate Gigabit Ethernet!

$ time cp wonderwoman-uhd-hyperx.mkv /dev/null
real 9m39.832s
user 0m0.940s
sys 1m43.010s
$ ll wonderwoman-uhd-hyperx.mkv
-rw-r–r-- 1 osmc osmc 58035255291 Mar 3 2018 wonderwoman-uhd-hyperx.mkv

(another update by edit for not being able to post a reply)

So this is probably the best I can optimize out of my current setup:

  1. Swithed back to a file on the 5400RPM SATA WD drive in faster OWC Thunderbay 4 Thunderbolt3 exterlal enclosure.
  2. Stopped other IO intensive services on the server.
  3. Added mount options to the autofs file for NFS (-fstype=nfs,noatime,nolock,local_lock=all,async)

$ ll kin.2160p.remux-no1.mkv
-rw-r–r-- 1 osmc osmc 55011086067 Jan 12 02:06 kin.2160p.remux-no1.mkv
-rw-r–r-- 1 osmc osmc 17308 Jan 12 02:06 kin.2160p.remux-no1.nfo
$ time cp kin.2160p.remux-no1.mkv /dev/null
real 7m49.472s

Results: net 117,176,500.55 bytes / sec file read speed, so very close to the theoretical 118,660,598 bytes/sec of TCP/IP on Gigabit Ethernet at 1500 byte MTU (https://www.gigabit-wireless.com/gigabit-wireless/actual-maximum-throughput-gigabit-ethernet/) and using jumbo frames for 123M theoretical bytes/s is not currently an option as stated by @sam_nazarko in Vero4K+ - Jumbo frames - #6 by nabsltd.
…and in between are the overheads for NFSv3, NTFS, CPU, TB3 etc. Hope this is a good reference point for the network capabilities of the Vero 4k+ , thanks for getting me started, @darwindesign! :slight_smile:

1 Like