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.
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.
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.
@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.
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:
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.