New Vero 4K / slow network performance

Help and Support
4

I personally prefer SMB as I want access from Windows machines as well and have setup proper credentials. Also I need some features that NFS does not provide and have as most probably do a heterogeneous environment (Windows, Linux and in my case even a Mac). Biggest no no is for me that NFS does not support user authentication and only IP based authentication. That’s a no go. Yes, I know you can setup NIS. Welcome back to the 80s. NFS is only enabled for me for OS network installations on that specific share.

Yes, NFS is a tad faster for streaming your files, but that is rarely a problem. For Kodi the point between SMB vs. NFS is rendered mute by the fact that we just fill a buffer and plays. The theoretical max performance difference because of less overhead plays absolute no role in the end. Any network throughput test do not reflect the actual usage case you have with Kodi.

If Kodi cannot fill its buffer fast enough for playback then you have a general network performance problem. For example 4K media with a very high bit rate that your network can barely handle to begin with.

But sure if you have no other requirements beside everyone can access a share from Linux then you can use NFS as well. And if you talking server to server transfer, well use ZFS. Hey, you can even use SSHFS or FTP. Really, doesn’t matter in the end.

Choose your poison. There is no right/wrong or better/worse. And for the Kodi usage case it does not matter at all, as long as your network, file server and configuration is proper; the filesystem you are using plays no real role.

Proper SMB setup with a Synology and a Vero 4K

On the Synology:

Control Panel → File Services → Enable SMB Service
Click on Advanced Settings

  • WINS Server: Leave Empty
  • Maximum Supported SMB Protocol: SMB3
  • Minimum Supported SMB Protocol: SMB2 (SMB1 if you have ancient clients that require a 30 year old version - if all clients support SMB3, wenn you can even turn off SMB2)
  • Transport Encryption Mode: Auto
  • Enable Opportunistic: Locking: Checked
  • Enable SMB2 Leave: Checked
  • Enable Local Master Browner. Not checked (unless you really want to, HDDs will not hibernate)
  • Enable DirtSort VFS module: Not Checked - no real benefit in server side sorting.
  • Veto Files: Not Checked
  • Allow Symbolic Links within Shared Folders: check if you use them
  • Allow Symbolic Links across Shared Folders: check if you use them and they go between shares

Then you have it setup nicely on your Synology. Check from your Windows client. It should be snappy even when you access folder with several 1000 files.

The Synology defaults are not very good as they kept it compatible with everything. Especially browsing shares is slow out of the box. Same for other NAS. There are a few more hacks you can do to the server side SMB configuration. But this is usually not needed unless you tempered with related stuff under the hood on your Synology or have some really huge file lists (e.g. 100,000+)

On the Vero 4K side:

As Kodi does not use libsmbclient properly (not going into details), it basically behaves like the 30 year old SMB1, we let the OS fulfill all our needs. At least libsmbclient allows you to configure stuff with a user config file. But why bother? It is still bad inside Kodi no matter what protocol version you are using - though for just streaming a file it is ok. But it makes stuff like scanning libraries/cleaning terrible slow. NFS is not much better inside Kodi, Better let the OS handle your network needs with Kodi whenever possible.

And SMB1 is not secure. Ransom Ware uses SMB1 security problems to propagate many times in the past. It was finally turned off in Win 10 per default in the Fall Creators Update if I remember correctly. About time. You can’t fix problems with a 30 year old protocol, especially when there is no reason to use it in the first place.

So we let the OS handle everything and it can even read ahead for a better caching experience.

To mount folders automatically we will edit /etc/fstab

Here is how you set it up nicely:

  1. Create a file for your SMB credentials in the OSMC user’s home dir. I named mine .smbcredentials The content looks like this:

username=USERNAME
password=PASSWORD

Just fill in what user you want to use to access your diskstation and the appropiate password. Saves us typing it later and other users cannot see the credentials. Just good practice.

  1. Edit the /etc/fstab files and add one line for each share like this:

//Diskstation/Movies /mnt/Movies/ cifs noauto,x-systemd.automount,vers=3.0,sec=ntlmssp,credentials=/home/osmc/.smbcredentials,uid=1000,gid=1000,iocharset=utf8

That’s all one line.

Also make sure you created the directory for mounting sudo mkdir /mnt/Movies

Let me go over the parameters quickly, so you understand them.

  1. Name of the share. They are in the format //SERVER/SHARE. If you have spaces in your shares you need to write them as \040 (it’s the character code for space as the character space itself is used as a separation character). If you have no proper local DNS resolution you can use the IP instead of the server name. But well if you have a Synology you probably setup a Dynamic DNS with reverse lookup zones anyway, with your router as a secondary DNS.

  2. Where to mount. We mount everything under /mnt in their own directory per share. Need to be created of course.

  3. cifs - tells the system it is an SMB mount. CIFS was the initial name for SMB. It was basically SMB1. Though newer versions are supported by Samba the parameters was not changed even tough SMB has not much in common with CIFS anymore. Yeah, just adds to the confusion.

  4. noauto,x-system.automount - we will automount the shares at boot time. Don’t worry Synology HDDs will still hibernate properly when there is no file access (unless HDDs have crappy firmware and never hibernate properly to begin with when appropiate)

  5. vers=3.0 - the SMB version we are using. Let’s go for 3. You can also use 2.0 or 2.1 if prefer that. But we are not doing anything fancy where 2.1 or above are lacking features in Samba’s SMB implementation and neither we are missing kernel support. Same stuff as on the Diskstation.

  6. sec=ntlmssp - security mode to authenticate. We are using what modern Windows versions are using.

  7. credentials=FILE - we point to the user/password file we created eariler

  8. uid=1000, gid=1000 = mapping the user/group we are in when accessing the SMB share to our local OSMC user so we see the proper username and group and not some cryptic values from the command line as user/group ID as the ones the NAS do not match the local ones, which they usually never do.

  9. iocharset=utf8 - to deal with special chars in filenames. We do not live in a 7bit ASCII world anymore.

After a reboot (or restarting the service) your shares should be there. SSH into the box and look at the directories. If you did everything correctly they should be accessible like everything else. And file access is controlled by the permissions you set on the Synology. And you can even set Symlinks easily!

I use them a lot to create duplicate files like having a custom Movie Sets in Kodi but still have file as well the movie in the proper location (e.g. Terminator shows up under my Schwarzenegger Set but as well under a Terminator Collection). Also files are linked from various shares into a main share and even from another server. For my symlinking needs. I just fire off one script that updates/remove links when I add new files.

I like symlinking in my library a lot as how it appears to the network is not necessarily the same as on the file storage itself. I simulate a low footprint virtual file system with it for Kodi to access. Kodi only accesses one share per media type on my Synology that only consists of Symlinks to other shares (hidden from network browsing) that even might be on different machines (can even be over VPN connections if you have the bandwidth).

This is one reason why I need SMB beside user authentication, as for NFS I would need to mount all the shares with the same name as symlinking is resolved on the client and not on the server. NFS is just leightweight, hence a tad faster but lacking more options.

Now the paths might be different if you scanned files into your library from SMB, NFS or whatever url before. But no problem we can use path substitution for it instead of rescanning.

Here an example how to do it in the advancedconfig.xml

<pathsubstitution>
    <substitute>
        <from>smb://DiskStation/Movies/</from>
        <to>/mnt/Movies/</to>
    </substitute>
</pathsubstitution>

With that we basically tell Kodi everytime it access the network URL it should use the path we defined. We just redirect it.

Now Kodi does not use any SMB itself, the OS handles it. You might see Kodi using SMB shares of course if you access file sources as network URLs. Well you can use the above path now as your new source folders and that problem is also gone.

With multiple clients you might need different mappings. I personally leave the sources always as SMB so I can easily map them to other directories on clients as needed - I scan from a Windows box where I encode my DVDs/Bluray/Recordings anyway. Don’t use Kodi as a player there at all. But well multiple clients, central library is a different topic.

Also make sure you setup the caching in Kodi - as already explained by other… As the Vero 4K has more RAM you can use usually more than on older device. Helps when data cannot delivered as fast as required. But only up to a certain point naturally. Anything in the 200-500 range should be fine. Though I am not sure anymore that Kodi still uses 3 times what is defined here (can someone verify that this is still the case?. Anyway tweak the size as needed. But it’s no magic pill. I currently have 200MB setup.

You find a lot of posts how to customize the caching here, though for the Vero future updates will probably have higher defaults out of the box (guess with Dec '17 update?)

2 Likes