New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

solved: NFSv3 on mergerfs: errors with Kodi/LibreELEC #294

Closed
thatso opened this Issue Feb 9, 2019 · 10 comments

Comments

Projects
None yet
4 participants
@thatso
Copy link

thatso commented Feb 9, 2019

Basically adding to this forum thread: https://forum.openmediavault.org/index.php/Thread/26027-NFS-problems-with-Kodi-streaming/:
I was streaming content from OMV 4 on a Terramaster F2-220 NAS (SSD install) to LibreELEC on an Odroid C2 for more than one year over gigabit ethernet LAN without any problems whatsoever.
Recently (starting with LibreELEC 9), playback randomly just stops or worse, the GUI freezes and I have to reboot. The kodi.log then reads:

ERROR: Read - Error( -14, read call failed with "F" )

nfsstat on OMV reads:

root@omv:~# nfsstat
Server rpc stats:
calls      badcalls   badfmt     badauth    badclnt
276809     0          0          0          0

Server nfs v3:
null             getattr          setattr          lookup           access           
12        0%     2186      0%     0         0%     195355   70%     5         0%     
readlink         read             write            create           mkdir            
0         0%     12168     4%     0         0%     0         0%     0         0%     
symlink          mknod            remove           rmdir            rename           
0         0%     0         0%     0         0%     0         0%     0         0%     
link             readdir          readdirplus      fsstat           fsinfo           
0         0%     0         0%     67072    24%     0         0%     12        0%     
pathconf         commit           
0         0%     0         0%

I know that Kodi uses libnfs. However, if I mount shares from the CLI with

LibreELEC:~ # mount -t nfs omv:/export/test /storage/test

nothing changes. On the other hand, playback from pure NFSv3 exports on a Debian box I've set up for testing is rock solid.
Hence, I assume that OMV currently does not play nicely with Kodi/LibreELEC regarding NFSv3 shares.
However, I have no clue where to start debugging.

@thatso thatso changed the title NFSv3 erors with Kodi/LibreELEC NFSv3 errors with Kodi/LibreELEC Feb 9, 2019

@votdev

This comment has been minimized.

Copy link
Collaborator

votdev commented Feb 12, 2019

Hmmm, i also have no idea. OMV does not do anything special, it only creates the NFS config files. So there shouldn't be a different to a normal Debian system. Maybe you should start comparing the settings files on your OMV and Debian system.

@votdev votdev added the 4.x label Feb 12, 2019

@thatso

This comment has been minimized.

Copy link
Author

thatso commented Feb 12, 2019

I know it is strange. Google brought up a few references regarding NFSv3 and this read error -14, however all of them are missing a solution or even any solid conclusion on what's going on.
So while I'm certainly not the only one hit by this effect, nobody has a clue what is wrong or even what side (OMV or Kodi) is to blame.
The exports file on my Debian test VM reads:

/srv/export/test 192.168.1.0/24(ro,insecure,subtree_check,no_root_squash)

while exports on OMV contains:

/export/test 192.168.1.0/24(fsid=1,ro,subtree_check,insecure,all_squash,crossmnt)
# NFSv4 - pseudo filesystem root
/export 192.168.1.0/24(ro,fsid=0,root_squash,no_subtree_check,hide)

which BTW reminds me that it might as well be an issue with mergerfs on OMV ...

I exclude ...squash as possibility because otherwise I should not have any file access at all (and I have a corresponding local Kodi user account on OMV which I spared on the test VM).

@CvH

This comment has been minimized.

Copy link

CvH commented Feb 12, 2019

I have /export/Share1 192.168.0.0/24(fsid=1,ro,no_root_squash,insecure,all_squash,async) at OMV since ages and it works with all kinds of HW and versions (Rockchip, AML S905/S912, Intel etc) for LE.

@thatso

This comment has been minimized.

Copy link
Author

thatso commented Feb 13, 2019

I did some more research and added noforget after going through the mergerfs docs. I already had the other recommended options, so for now these are in place:

defaults,allow_other,direct_io,noforget,use_ino,category.search=newest

The first few tests with heavy skipping forwards and backwards during playback in LibreELEC look very promising. No more sudden freezes so far. I will do some more testing now and report back.

@thatso thatso changed the title NFSv3 errors with Kodi/LibreELEC NFSv3 on mergerfs errors with Kodi/LibreELEC Feb 13, 2019

@ryecoaaron

This comment has been minimized.

Copy link
Contributor

ryecoaaron commented Feb 13, 2019

I think this issue can be closed since this is a mergerfs setup issue and not an OMV issue. This is also why I don't have the problem (not using nfs on top of mergerfs) with nfs. On a side note, if you aren't doing heavy writes to the disk, you should remove direct_io. That may help with your issues as well.

@thatso thatso changed the title NFSv3 on mergerfs errors with Kodi/LibreELEC solved: NFSv3 on mergerfs: errors with Kodi/LibreELEC Feb 13, 2019

@thatso

This comment has been minimized.

Copy link
Author

thatso commented Feb 13, 2019

Ok, I've been testing with noforget for several hours now and the problem did not resurface so far. Before that, playback almost instantly crashed. I strongly suspect the complete rewrite of the Kodi videoplayer to be the culprit.

@ryecoaaron: do you enjoy trolling? You jump in telling it is "not an OMV issue" while NFS and mergerfs are part of OMV and brag about not having this kind of problem, which is not helpful at all. At the same time you suggest closing the issue because you don't have this problem. So, thank you for nothing.

@thatso thatso closed this Feb 13, 2019

@ryecoaaron

This comment has been minimized.

Copy link
Contributor

ryecoaaron commented Feb 14, 2019

@thatso Excuse me for trying to help. If you would have mentioned that you were using mergerfs in the forum (maybe I missed it if you did), then I would've been able to help much earlier.

I am sure as hell not trolling or bragging about not having the problem. I help a lot of people on the forum who aren't having the issue either which helped me eliminate OMV causing the problem.

When I say it isn't an OMV issue, that is because I know how OMV writes the config file and it isn't the problem. In defense of Volker, an nfs config file is hard to write incorrectly. If there is a problem, it would be related to the unionfilesystem plugin which is NOT OMV. It is omv-extras - a third party plugin repo I started and the plugin is something I maintain. I am just trying to save Volker from wasting his time when I know what isn't the problem. I suggesting closing this issue to move the discussion back to the forum.

But since I am doing nothing for you and I'm just an asshole, I will go away...

@thatso

This comment has been minimized.

Copy link
Author

thatso commented Feb 14, 2019

@ryecoaaron: so you are a troll. Read your first comment slowly one more time and tell me how anyone should have figured out the whole backstory you explained afterwards.
'nuff said

@ryecoaaron

This comment has been minimized.

Copy link
Contributor

ryecoaaron commented Feb 14, 2019

I wasn't blaming you for not mentioning. I was just commenting that I would've been able to help sooner.
And if a troll spends years helping people, money on dns & infrastucture to support omv-extras & development, and hundreds of hours writing plugins that I don't use, then I will take it...

@votdev

This comment has been minimized.

Copy link
Collaborator

votdev commented Feb 14, 2019

@ryecoaaron: do you enjoy trolling? You jump in telling it is "not an OMV issue" while NFS and mergerfs are part of OMV and brag about not having this kind of problem, which is not helpful at all. At the same time you suggest closing the issue because you don't have this problem. So, thank you for nothing.

@thatso Please stop that flame war, @ryecoaaron was right with saying it's not part of the official OMV. Please understand that we do not have the time to write the whole background everytime such issues come up, otherwise we could not do anything else during the day.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment