Yeah I don’t know. Thanks for the help. I can’t get samba to work at all. Has to be a setting on the syno I’m missing but I’ll leave that alone for now. If I start having issues again I’ll revisit it
Stay with NFS as it will perform better.
I don’t think you posted, but what does your autofs map file look like for the nfs mounts? Another thought I had was it’s something to do with block sizes.
If you are not familiar you can get Kodi to use the NFS path instead of the system mount without editing your sources or dumping your db by just tweaking your advancedsettings.xml on each of your boxes. If you ever figure out why the system mount is acting up you can reverse it by just removing the path sub.
2 Likes
this?
Yes. Try this instead (if you are willing to do more testing).
/mnt/movies -fstype=nfs,noatime,vers=3 192.168.0.107:/volume1/web/movies1
This will force NFS to V3, and the noatime option probably isn’t needed, but can have a minor impact on access (mostly during a library scan)
This needs clarifying:
Same results as what? Are we now to conclude that this is nothing to do with the upgrade to the 4.9 kernel?
I don’t think it does. I had the same issues on 3.14 kernel on one of my devices. I tested there first nfs via kodi and it worked then moved on to the 4.9 kernel box and works there too
Sorry, but what is “it” in this context: your initial inability to get through a movie or the subsequent problems with getting mounts to work?
This is getting more confusing. Have the system (autofs) mounts ever worked? If they did work previously, when did you first start having the problem?
'It" is getting through a movie. I had always used fstab with no problems. Upgraded to testing branch and thats when problems began. At least i think its when it started. Could just be a coincidence. Switched to autofs to test a few days ago to try something diff then fstab.
Since you have reproduced the problem on 3.14, then the 4.9 testing has nothing to do with the problem. It’s something on the Syno. Has it updated lately?
The only difference between fstab and autofs is how they handle a server going away. The underlying method of mounting is exactly the same.
Here’s a quick one-liner that I’d like you to try on the Syno box (as root):
ethtool -A eth0 rx off tx off
See if “it” still persists on the 3.14 box. If the new settings cause a major problem, you can always set them back to “on” – and the new settings also won’t survive a reboot of the Syno.
Testing the autofs change you asked to test and immediate buffering at start and locked up so i stopped movie. Went to play it again and got the sad face and it rebooted. tried again and buffering for 10 seconds but then movie started and so far has continued to play. The syno did update within the last few weeks…
ok. I have to step away for a little bit but will test a little later. I’m going to leave this movie playing to see if it makes it through without quitting
Movie is still playing so I want to leave things the way they are for now as it seems to be working with the change that @bmillham suggested
Let us know what happens. Make sure you try several movies (and you may want to make the same change on the TV Shows mount).
I will and already made the change on the tv show mount
Just watched a movie on the vero4k+ and all good. Back in business. Thanks again for the help. So for my own knowledge the issue was the version of nfs for some reason? You forced version 3.0 with your line of code?
Yes, that forced the mount to use NFS3. The idea to try that was inspired by a comment to me by @darwindesign.
I have no idea why it would be different than using NFS4. A wild guess would be a difference in block sizes, or maybe UDP vs TCP.
I’m glad that this worked for you!
1 Like
Excellent!
1 Like