Within the last day or so I have been doing some testing on very recent alpha/beta releases of CoreELEC (v8.95.3 on a Beelink Mini MX III "classic" / AmLogic S905 / gigabit ehernet) and LibreELEC (8.90.005 on my current HTPC, a Zotac Zbox BI320 / Intel 2957U / gigabit ethernet). These both include recent vintage Kodi 18.0 BETA releases. I found a number of small issues related to each of these "standalone" Kodi implementations, and I either already have reported those, or will soon report all of those issues to the respective maintainers.
One serious performance issue I noticed however is definitely a straight Kodi issue. I'll describe it here, get feedback, and then post it as a formal bug report in the bug tracker, if that still seems appropriate.
My test setup is as follows: I've got a FreeBSD NFS (2/3) server in one room (office) hooked to the local LAN in the room. Also on that LAN is my ASUS RT-AC56U WiFi router ("AC1200"). On the NFS server I have numerous DVD ISO rips. Meanwhile, out in the living room, one wall and about 15 feet away, I have a Linksys WUMC710 ("AC1300") media bridge. I've previously clocked the WiFi connection between these two WiFi devices at over 230Mbps (actual) using iperf. It is a good, solid, stable, and fast connection. I have the Zotac Zbox and/or the Beelink boxes hardwired via short cat5e cables to the WUMC710. (Note that the Zbox, the Beelink, and the WUMC710 all have gigabit ethernet ports.)
Mounting the NFS volume(s) using Kodi's built-in NFS client, as present in the recent versions of LibreELEC and CoreELEC noted above, and then trying to simply start playback on any one of the several DVD ISO rips I have results in a dramatic stall before playback actually begins (during which the lights on the front of the WUMC710 blink like crazy). I have measured the duration of the stall before playback begins to be as much as 30 seconds (on the Zbox) and as much as 47 seconds (on the Beelink). These pauses are both annoying and also inconsistent with all of my past experience with Kodi on various platforms.
In contrast, when using Linux's own built-in NFS client code, which can be achieved simply via the procedure described here, the delays when starting up playback of a DVD ISO rip are dramatically reduced to between 2-4 seconds, max, depending on the specific ISO being played. This is with all of the exact same hardware, including the exact same WiFi equipment and associated settings, and even many of the exact same DVD ISO files.
The bottom line is that in the scenario described above (i.e. starting to play a DVD ISO rip) the apparent performance of Kodi's built-in NFS client is measurably and dramatically worse than if one performs the same operations with all the same hardware and media files, but using Linux's own built-in NFS client code.
I look forward to any questions and/or comments.
P.S. Just to be clear, I am by no means suggesting that the use of SMB shares, regardless of what software (i.e. either Kodi or the underlying OS) is providing the SMB client code is ever superior in performance to NFS for ordinary networked file sharing. Based on experiments that I performed some long time ago, my clear impression is that SMB consistently performs much worse than NFS in virtually all cases. However as noted above, the specific NFS client code being used may also dramatically affect performance.
One serious performance issue I noticed however is definitely a straight Kodi issue. I'll describe it here, get feedback, and then post it as a formal bug report in the bug tracker, if that still seems appropriate.
My test setup is as follows: I've got a FreeBSD NFS (2/3) server in one room (office) hooked to the local LAN in the room. Also on that LAN is my ASUS RT-AC56U WiFi router ("AC1200"). On the NFS server I have numerous DVD ISO rips. Meanwhile, out in the living room, one wall and about 15 feet away, I have a Linksys WUMC710 ("AC1300") media bridge. I've previously clocked the WiFi connection between these two WiFi devices at over 230Mbps (actual) using iperf. It is a good, solid, stable, and fast connection. I have the Zotac Zbox and/or the Beelink boxes hardwired via short cat5e cables to the WUMC710. (Note that the Zbox, the Beelink, and the WUMC710 all have gigabit ethernet ports.)
Mounting the NFS volume(s) using Kodi's built-in NFS client, as present in the recent versions of LibreELEC and CoreELEC noted above, and then trying to simply start playback on any one of the several DVD ISO rips I have results in a dramatic stall before playback actually begins (during which the lights on the front of the WUMC710 blink like crazy). I have measured the duration of the stall before playback begins to be as much as 30 seconds (on the Zbox) and as much as 47 seconds (on the Beelink). These pauses are both annoying and also inconsistent with all of my past experience with Kodi on various platforms.
In contrast, when using Linux's own built-in NFS client code, which can be achieved simply via the procedure described here, the delays when starting up playback of a DVD ISO rip are dramatically reduced to between 2-4 seconds, max, depending on the specific ISO being played. This is with all of the exact same hardware, including the exact same WiFi equipment and associated settings, and even many of the exact same DVD ISO files.
The bottom line is that in the scenario described above (i.e. starting to play a DVD ISO rip) the apparent performance of Kodi's built-in NFS client is measurably and dramatically worse than if one performs the same operations with all the same hardware and media files, but using Linux's own built-in NFS client code.
I look forward to any questions and/or comments.
P.S. Just to be clear, I am by no means suggesting that the use of SMB shares, regardless of what software (i.e. either Kodi or the underlying OS) is providing the SMB client code is ever superior in performance to NFS for ordinary networked file sharing. Based on experiments that I performed some long time ago, my clear impression is that SMB consistently performs much worse than NFS in virtually all cases. However as noted above, the specific NFS client code being used may also dramatically affect performance.
