Hi all, after recent updates - I am unable to play any files from my NFS server. I tried connecting to SMB and it failed to connect as well.
I have uploaded my logs after replicating it on 2 1080p h254 MKV files off my NFS server.
https://paste.osmc.tv/ecufevipop
Hope someone can help me out here. Thanks!
<source>
<name>FireCuda 520</name>
<path pathversion="1">smb://192.168.88.254/FireCuda 520</path>
<allowsharing>true</allowsharing>
</source>
<source>
<name>FireCuda 520</name>
<path pathversion="1">nfs://192.168.88.254:2049/Volumes/FireCuda 520/</path>
<allowsharing>true</allowsharing>
</source>
2022-11-08 03:22:56.035 T:3026 ERROR <general>: Read - Error( -4, read call failed with "Command was cancelled" )
2022-11-08 03:22:56.035 T:3026 ERROR <general>: Process - <nfs://192.168.88.254/Volumes/FireCuda 520/Unwatched/Movies/R.I.P.D.2.Rise.of.the.Damned.2022.1080p.BluRay.x264.DTS-HD.MA.5.1-MT.mkv> source read failed with -4!
Thanks for helping to troubleshoot. I am using my Mac mini as a sharing server and I have both NFS and SMB setup although I only use NFS when streaming to my Vero 4K.
I haven’t edited anything nor added the port number to the NFS source and things were streaming fine until recent updates. I added SMB as a source to see if it was an NFS server issue but it still shows an error and wouldn’t play any video files I throw at it.
I have attempted to delete and readd the sources, both SMB and NFS. They populate the file and directories but would fail to play the video files.
https://paste.osmc.tv/akujadiyab (uploaded new log with me navigating to both NFS and SMB sources and trying 2 movie files respectively)
I will try to do an iperf test soon once I have time but it doesn’t seem to be a network issue because I can remotely access my server externally and internally. The Vero 4K and Mac mini are connected to the same 2.5G switch over LAN as well.
You still have two source definitions with the same name <name>FireCuda 520</name>.
While I agree it might not be related to your issue it is also not correct. So maybe remove your sources.xml via command line and define them from scratch.
Also do the iperf3 test just to be sure.
Next suggestion would be to switch to kernel mounts.
It’s been a while – I hope you’re well.
If you changed anything in your network recently I’d usually look there first. Have you checked that the IP stays the same for the NFS server?
If you copy that sources.xml to another Kodi device (if you have one); are you able to play content?
Can you ping the NFS file server from your Vero?
Sam
Hey @sam_nazarko
Yes it has indeed been a while! I have been well, just started a regional Customer Success role 2 weeks ago and been busy. I hope you are well too!
I didn’t change anything in my network recently except perhaps upgrading my M1 Mac mini to MacOS Ventura 13.0.1 and I checked that my NFS configurations are still the same as before with NFS Manager 5.6.
I have a Raspberry Pi 2 that is still running March 2022 update and I tried to play back content with the same NFS source and it showed the same “One or more items failed to play” error. So I suspect it probably isn’t OSMC update that is causing this issue.
But as you can see, the iperf3 test checks out above. I have no issue accessing the server outside of my local network (via SMB and SFTP) as well. Really scratching my head on this one. If it was an NFS issue, it doesn’t explain why playback via SMB would fail too.
Network speeds look good (for Vero 4K)
If NFS and SMB are not working, I’d suggest that there’s some kind of new firewall issue that may be at play.
Look for IP address changes in case you’ve set some rules in the past and things have changed there.
Glad to hear things are going well for you.
Sam
Looks OK, as Sam wrote maybe a firewall problem.
Anyway maybe try the autofs solution I wrote above. If that doesn’t work then even more likely pointing to network/firewall issue.
@sam_nazarko I checked through all my router and firewall settings and nothing has changed and I don’t have an issue mounting over SMB on my Mi Box S and playing back media using Android TV. All wired and connected on the same 2.5G switch.
@fzinken Yeah I think I will try to mount using autofs soon when I have time again and see how it goes.
At this point, I suspect it could be a MacOS Ventura issue - perhaps some part of the new OS update doesn’t play well with Linux/Debian mounting SMB/NFS. It seems like it would show all the file and directory listing fine on OSMC but just wouldn’t play any media or transfer files.
I have zero issues accessing the server via SMB and SFTP using Android file managers, video players etc. Both over internal and external networks. I have another Xiaomi TV Stick 4K and used MX Player to access my SMB server over the internet at another location (my office) and plays media just fine too. It’s just so weird.
I hope you are doing that using a VPN.
What really wonders me here is that issue is similar for SMB and NFS as it is totally different technology. This makes me think that it might be a package size issue that makes it stop.
Sorry for the lack of updates - I ended up using the autofs solution, it didn’t work for NFS but worked for SMB. There was someone else with the exact same issue as me after upgrading to MacOS Ventura.
Also found this on the known issue with MacOS Ventura Kernel/NFS:
https://discussions.apple.com/thread/254487367?answerId=258389586022#258389586022
The kernel of macOS Ventura may cause NFS communication problems with third-party operating systems if the buffer size is greater than 64 KiB: When macOS 13 or later tries to send data to NFS software of a different operating system type (especially Unix systems with “System V”-like behavior), the network connection may fail if a buffer size greater than 65,536 bytes is negotiated in send direction of macOS. This can affect both server and client features. Access on the client side stops responding, or experiences severe performance problems.
Workaround: This is a known issue with the kernel of macOS 13 or later. As a workaround, limit the NFS buffer on the client side for communication in direction to the non-macOS system to 65,536 bytes. For example, if macOS is used as a server, add the option “rsize=65536” to the mount command of the client. If macOS is used as a client, add “wsize=65536” to its mount command. The latter is equivalent to establishing the additional option Client Tuning > Write buffer size: 65536 in NFS Manager, either for the client, for each affected mount, or for each affected automount.
