I’ve found that it’s much better to import by going to WANTED > Manual Import.
I am also using CIFS shares. My issues was different than yours, though. It just simply couldn’t tag or identify most of the content. (However, it identifies it correct 99% of the time through the WANTED > Manual Import.)
I think the problem here is it’s not showing anything to Sonarr (which does seem to be a platform issue when I looked at the thread linked above). Manual import uses the same file browser to find the folder and isn’t useful if you can’t add the series because Sonarr can’t see the contents.
I now know the source of my problems. They are in relation with the particularities of the platform that I am running, which mixes a 64 bit arm64 kernel with a 32 bit armhf userland, and the fact that mono armhf was not compiled with large filesystem support.
Among the options I had was to use mono arm64 (but id id not like the 64 bit dependencies it would bring to my 32 bit userland) and recompile mono armhf with large file system support. As I was working on this last option, I found an easier way out. From mount.cifs man page:
Inode Numbers
When Unix Extensions are enabled, we use the actual inode number provided by the server in response to the POSIX calls as an inode number.
When Unix Extensions are disabled and “serverino” mount option is enabled there is no way to get the server inode number. The client typically maps the server-assigned “UniqueID” onto an inode number.
Note that the UniqueID is a different value from the server inode number. The UniqueID value is unique over the scope of the entire server and is often greater than 2 power 32. This value often makes programs that are not compiled with LFS (Large File Support), to trigger a glibc EOVERFLOW error as this won’t fit in the target structure field. It is strongly recommended to compile your programs with LFS support (i.e. with -D_FILE_OFFSET_BITS=64) to prevent this problem. You can also use “noserverino” mount option to generate inode numbers smaller than 2 power 32 on the client. But you may not be able to detect hardlinks properly.
Markus, I plan to move my entire library from ext4 to ZFS in about 2 weeks. Just waiting for new drives to ship so I can setup a raidz1. I’m running ubuntu 16.10 x64. I’m not compiling anything, just using apt-get to install various packages.
That’s exactly why I mentioned XFS, coz it has 64bit inodes and any filesystem entry with an inode that’s larger than 4294967295 won’t be visible to the 32bit mono.