Strange library issues after moving to NFS

OK, I’ve been using my new Vero 4K for a month or so now, very happy with it.
However, I’ve noticed that some items haven’t been scanning to my library properly and I’m not quite sure what to do with it.

Just some background:
I have a Windows 2012 R2 Essentials server running DrivePool. Before the Vero, I was using LibreElec to connect to SMB Shares (/Movies, /TVShows etc) and a MySQL database to share my library with a FireStick running Kodi. No problems.

When I plugged the Vero in I couldn’t get it to see any of my SMB shares, so after reading through the forum a little I decided I’d just use NFS instead, which seems to have fewer issues. So I installed the NFS Server feature in Windows and shared my folders that way. I also put a path substitution into advancedsettings.xml so that my previous library entries would still work properly.

This has been working fine (and actually still is) until I noticed a few weird things in my library - TV shows appearing that I had no idea about but with episodes belonging to series that I do have. I ignored all this… until yesterday when it just refused to show The Walking Dead S08E01 no matter how many ways I tried to add it to the library manually.

I took a look at the logs and found all sorts of weird stuff in there - strange characters in episode titles, really weird stuff. I thought that the MS NFS Server might be mangling file names, but when I view them through File Explorer (or whatever it’s called) in the System menu they appear fine.
I’ve attached a link to the log file:
https://paste.osmc.tv/uzugulogag
see various lines like
“08:46:45.845 T:4089443312 ERROR: SQL: [MyVideos107] Undefined MySQL error: Code (1366)
Query: insert into files (idFile, idPath, strFileName) values(NULL, 556, ‘Star Trek Enterprise S03E21 - E� (05May2004).avi’)”
This file shows up fine (without the weird characters) when browsing as SMB or NFS.

Any ideas? It’s only happened since I switched to NFS from SMB. I’d switch back to SMB if I could make the Vero see the Windows 2016 server shares, but I can’t. And no comments about switching to a Linux server please!

Thanks

To be honest if you have a Windows server you might want to stick to SMB as I am not sure how good the Windows NFS server is.

From the log file it could be a utf8 problem either on server or client

Indeed, this looks like a mapping problem of invalid characters:

The example problem file name in NTFS is most possible

“Star Trek Enterprise S03E21 E² (05May2004).avi”

where ‘²’ is a valid character within filenames on NTFS with Windows.
Unfortunately MySQL got something like “�” instead of a proper UTF-8 which is an invalid character therefore error 1366.

So, if your Windows 2012 R2 Essentials supports NFSv4 or NFSv4.1 it should support the correct UTF-8 mapping.
I do not know how to specify NFSv4 in OSMC GUI when binding the source. I use the /etc/fstab method to map the NFS shares into OSMC, just an example line:

synology-ds214se:/volume1/tv_recordings /mnt/tv_recordings nfs4 defaults,x-systemd.automount,noauto 0 0

as you can see, here you can specify what protocol and version the Linux OS should use for NFS.

Another workaround is just to avoid any special character in your filenames on Windows, so replacing ‘²’ by ‘2’ should do it as well. So the only interesting part for the metadata scraper searching on thetvdb.com is the string “Star Trek Enterprise S03E21”, the rest is of no interest to identify the video and get the meta data.

I don’t know if this will help, but adding the iocharset=utf8 option to the fstab entry is worth trying.

Thanks, I’ve been checking a few things out.
Looks like the NFS in Windows Server 2012 is NFS 2 or 3, no 4 (or 4.1). Can’t seen an option for UTF encoding.
Since this only happened when I changed from SMB to NFS, I figured I’d just make SMB work.
Thanks to a how-to on here, I mounted the folders from /etc/fstab and they work fine - in fact, much quicker than NFS was (or at least it looks that way). I scanned the folders and all the library items that wouldn’t scan before work perfectly now.
So it looks like the NFS server in Windows 2012 has caused these issues.

1 Like