If you have VIDEO STUTTER please check THESE SETTINGS (updated)

Does it make sense to switch to an NFS share instead of SMB when using high bitrates?

 

I haven't try but the NAS system works better under SMB than NFS.... then pointless.

 

I know this doesn't help you and it is just a personal observation, but I've said many times before that I don't believe boxes like these should even have WiFi! Ok for online streamers with low bitrates and an encode ladder for when things get funky, but not for devices like these.

Yes modern WiFi protocols can provide sustained high bitrates, but in real life, the vagaries of radio transmission do their very best to interfere with these (pun intended!).

 

Yes, I know your considerations which I respect but many users, me included, need to use WiFi. I moved from Zappiti to Zidoo for its great performance. Sorry, but WiFi is not questionable here.

 

Wi-Fi can handle high bitrates; the problem seems to be Poster Wall. Or how do you explain the fact that Plex runs smoothly but stutters when using Poster Wall?

 

I already said that "modern WiFi protocols can provide sustained high bitrates" but I then qualified it with: "but in real life, the vagaries of radio transmission do their very best to interfere with these".

The 2.5 and 5GHz bands are highly congested, not only with Wifi, and of course the more dense the WiFi usage, the more problematic it becomes, but also other devices using that band and of course other wideband EMI - The WiFi protocol uses sophisticated error checking and mathematical counter measures but all of these lead to a reduction in performance dependent on the level to which they need to be deployed.

I can't comment on Plex since I don't use it, but HT (the posterwall) has no bearing on performance since it's essentially just a UI and not a player.

 

The fact that Plex doesn't stutter at high bitrates is likely because Plex and HT use different streaming methods. Plex streams content via the HTTP protocol. The Plex server packages the data into an optimized, continuous web data stream. The Plex app on the Zidoo receives this stream and uses it to fill a very large, dynamic memory buffer (cache) of the Android operating system. If the network fluctuates for two seconds, the player doesn’t notice because it has already loaded 20–30 seconds of the movie in advance.
With HT, the Zidoo’s own player accesses the NAS via the SMB protocol (Samba). SMB was originally developed to copy Office files over a network, not to stream 4K media. The Zidoo player requests the file in “real time” in blocks. The Zidoo player’s buffer for SMB connections is extremely small (often just a few megabytes). If the data stream drops out for even a millisecond during a 150 Mbps peak in the movie, the buffer empties immediately and the image freezes.

Hence my question: could switching to NFS resolve this issue? Unfortunately, I haven’t been able to set up an NFS share under OMV. The Zidoo player does recognize the NFS IP, but I still can’t access it.
Could someone perhaps test whether stuttering at high bitrates also occurs with an NFS share?

 

That won't help.
As Mark wrote earlier,
WiFi connection = problems, especially at high bitrates.
Simply connect with a cable and see if the problem persists.
I also switched to Wi-Fi 6 once.
Now I have three-channel Wi-Fi 7 and the problem persists. It's much less frequent, but it still persists.

 

Once again, the Wi-Fi connection isn't the problem; rather, it's the insufficient buffer values in the SMB share.
I tuned the SMB share in OMV by increasing the send and receive buffers. In the SMB settings, I added the following:
socket options = TCP_NODELAY IPTOS_THROUGHPUT SO_RCVBUF=262144 SO_SNDBUF=262144
With these settings, minor stutters and dropouts have been eliminated.

 

So, here's the thing..I've been off doing other stuff (emu scene)....I had massive stuttering on certain games, i switched between game mode and standard...game mode = no stuttering.....standard = stuttering...came down on my panel to one simple setting = motionflow off...now no stuttering in standard mode or game mode....funny old world eh?

 

?

 

Emu = Emulation.

Turns out it caused a cascade failiure - the momemnt there was a dropped frame from the emulator, it caused the motion interpolation to try and smooth out what it though was judder,...and then that its, its over, as it causes a destructive loop,, until you stop the emu and start again, and guess what happens? yep. Off, for more reasons than people think.

 

Zidoo implementation of NFS is buggy and requires NFSv2 to be enabled.

See here for details: https://forum.zidoo.tv/index.php?threads/is-nfsv4-supported.100157/#post-248289

 

Do you mean NFSv3? NFSv2 has too many restrictions for streaming (file size, block size).

NFSv3 works just fine here.

 

No, I mean you have to enable NFSv2 in order for NFSv3 to work. The details are in the linked thread. Reply #5 has the diagnosis and reply #6 has the suggested fix (given some assumptions).

Agreed that NFSv2 is useless, but unfortunately the Zidoo implementation still insists on using the old RPC protocol that was deprecated in the 1990's. I can't imagine that this would be a difficult fix for the developers, if only someone could make them look at it. The hard work of diagnosing the root cause has already been done for them.

The reason it may work for you is because your NAS may have an old kernel where NFSv2 is still enabled. Modern systems do not enable NFSv2 and will often not even enable NFS over UDP.

 

My Zidoo-NAS doesn't work under NFS from the first day.

 

Ah, ok - but the server's RPC reply is regarding the version of MOUNT used and not the NFS version - NFSv3 is perfectly happy with v1. My NAS drives (WD EX2s) support NFS3 only and do not support v2 in any way according to the WD Knowledgebase and their firmware is up to date, but presumably are happy with MOUNT v1.

Never mind the archane way shares need to be mounted, this is another reason NFS is a PITA.

But I completely agree, using Mount v1 makes absolutely no sense with NFS3.

Would this not need a later version of mount.nfs or does that not apply here?

 

Linux uses a combination of user space and kernel to provide NFS services. If /etc/nfs.conf has vers2=no it will disable the old protocol versions and insist on version 3.When a server turns off NFSv2 and only enables NFSv3 or higher, as described above, it won't work with the Zidoo simply because the Zidoo client will never proceed past the mount stage. If you force enable the v1/v2 mountd protocol, then the Zidoo client will get past that hurdle and will subsequently use NFSv3 to actually access the NFS export.

Yeah, NFS prior to version 4 is trickier than it needed to be, but NFSv4 is mostly OK. The mounting protocol is part of NFSv4 and therefore rpc.mountd will not be called by the client at all for NFSv4 mounts. Full support for NFSv4 on the Zidoo would make this complexity go away for a large number of users.

No it does not and it never did in the first place. It's just baggage carried over from reusing 3rd party code and not understanding what it does, past "it compiles and runs without crashing". Not blaming, that's how these boxes get developed. It's only field testing and user reports that surface these issues - a good team will act on the bug reports, fix them and add the failure scenarios to their testing protocol.

On the NFS server side it would make no difference. On the Zidoo client side, I don't know how they implemented NFS mounts. I doubt that they use standard Linux mount mechanisms and call out to command line utilities, so a new mount program would probably not help. Even if they do use the command line utilities to manage the mounts, this would probably be solved by adjusting configuration files and mount options. It's very likely, that leaving most of the options out completely, would have the best chance of success. That's because the protocol and appropriate versioning should be negotiated if it is not explicitly given. Given that the Zidoo client does not have any knowledge about the NFS server configuration and no way for the user to provide it, it would make sense to omit any setting that can be negotiated.

When I did the digging into the problem more than a year ago, I figured that they most likely used libnfs to manage the NFS mounts and that it's all done from user space. If that is the case, the change will have to be done at the source code level to use the correct rpc version calls.

 

Great - appreciate the breakdown. This is most definitely not my area of expertise!

I've trawled through a recent firmware file and can't find any evidence that libnfs is used - no libnfs.so, no dependencies listed in apps and not documented in freeware licences. There are FFMpeg shared objects and I know they can be used as network handlers so maybe that's it?

I'd like to take this to the devs and I'm not sure of the best and simplest approach. Such things need to be distilled as short and as unambiguously as possible.

Do you think it would be best to say something like "Although NFS v3 is supported, the rpc.mount daemon version is incorrect which means correctly configured NFS servers cannot create NFS mounts - it appears to be using rpc.mount version 1 and it should be v3"

 

That's a good summary, but I think you should definitely include a link to https://forum.zidoo.tv/index.php?threads/is-nfsv4-supported.100157/#post-248289 which has the packet capture summary. I think that a developer will appreciate the detail.

I would also probably change the "correctly configured NFS servers" to explicitly point to the config option. I propose "NFS servers with vers2=no in /etc/nfs.conf", which should allow the developers / QA dept. to reproduce the issue. Aiming for a succinct version:

Connections to NFSv3-only server with "vers2=no" in "/etc/nfs.conf" fail because Zidoo uses rpc.mount protocol v1 instead of v3. https://tinyurl.com/mountdv3 has packet capture and analysis."​

Hopefully this is short enough, yet specific enough to get Zidoo to act.

Thanks!