is there a way for me to make it work on 9.2.6?
It can be done by backporting the newer kernel (with drivers that support the newer GPU) onto the 9.2 codebase. There are deliberately no guides and HOWTO instructions on that kind of thing. If nightlies work, you have a solution.
It's hard to describe my thoughts. The add-on name sounds like pirate shitware; but choosing dubious sounding names isn't against forum roles. Using a ton of code obfuscation isn't open-source minded, but again we don't have any explicit rules that say this is bad and against forum rules. The "I promise my code doesn't do bad stuff" is probably well intentioned but also seems to send the wrong vibe. TL/DR; it's all probably "legitimate" but my instincts are telling me this is shady and binning the thread will avoid drama.
If you poke around in Escalade's GitHub repo you'll find some prior art for adding an NFS server. It's not something we've ever felt the need for in core images as Samba works well enough and most folks will just get confused. FWIW, I've always used SMB and never had any issues (other than occasional self-inflicted mistakes). It might not be "fastest" but it's always been "fast enought" .. over Ethernet of course.
Random guess .. increase the settings level to advanced or expert, it might be hidden in basic.
No logs = No problem 
I have no clue about remotes, sorry..
Are the Matrix's addons compatible with Nexus or addon writers will have to redo them yet again?
Matrix/Nexus are both Python3 so add-on differences are minor and unlikely to require much effort from authors.
Enable "Adjust refresh" and configure the whitelist for 1080@60/59.94/50/24/23.976 and 4K@60/59.94/50/30/29.97/25/24/23.976 and set the Kodi desktop to 1080p@60. Read https://wiki.libreelec.tv/configuration/4k-hdr
"Team Kodi" is more accurately described as "small group of developers doing their own thing with occasionally overlapping interests" and as is common with non-commercial FOSS projects there is not much product management and no schedule. One of the few things its developers have ever consistently agreed upon is the need to reduce the complexity and improve maintainability of the codebase. That's the prime driver and motivation for the V4L2 long-term technical direction. Linux is inherently a fragmented ecosystem so we need to follow standards and be an advocate and agent-of-change for the establishment of those standards.
The Kodi debug log shows a connectivity/networking issue with typical stream stall and reconnect sequence. It also shows you playing pirated media .. and at that point I lost interest.
Single core, 1 go ram, x86, 32 bits model.
Our codebase dropped x86 support in 2015 back in OE 5.x days, so there are no LE releases that will run on it without a pile of detective work to figure out how to reinstate support and build a custom 32-bit image - it can be done, but it's not simple and there are no guides or willing staff volunteers for the quest - and as others have said, the Kodi experience once you finally get there isn't going to be great. An RPi kit will be much more rewarding for Kodi (suggested minimum RPi3B+ for 1080p or 2GB RPi4 for 4K and better experience) and also opens the door on the immense ecosystem of resources for other projects you can use an RPi board for.
It's a completely different codec so
At least 2 add-ons depend on this module, others might also depend on it.
How can this be best solved?
Flag the issue to the add-on author via their support thread in Kodi forums. Their code needs to stick to the default modules bundled with Kodi or they need to bundle the module (often as a supporting add-on) in order for Kodi to import and support it.
Are you guys on berryboot ?
LE has a long history of issues with BerryBoot which all originate in BB providing a different kernel build/config to what LE expects. Our advice is to avoid BB .. particularly if you want support from staff in these forums.
I deleted all Matrix images from my share 3-4 months ago when I switched to Nexus and renamed the thread. Even if you find a Matrix image it will perform worse and be less featured than the current Nexus images.
what can i do?
Share system log files?
do you see the vendor-specific ARM-based stuff as the 'future' of Kodi?
Team Kodi has been pursuing a "standards" based approach since 2016 and it's the reason Android now works very well. Linux is iinherently more complicated but a lot of the kernel frameworks are now in place and stable. Supporting older and current hardware has challenges as it means rework to existing codebases and commercial interests rarely fund work on old chips. However Google forcing Android device vendors to get ever-closer to upstream means future chip generations will increasingly have support written around the stable APIs and convergence will come. ARM devices are increasingly performant, and Intel stuff is still available (at a price) for anyone needing more.
