It is related to CONFIG_USB_UAS in the kernel, which is enabled in the LE kernel (so probably in OE as well) although I also found comments on github that might indicate this is disabled on the pi side: dwc_otg doesn't support scatter-gather transfers · Issue #875 · raspberrypi/linux · GitHub
I'll flag it to someone who might know more.
There's this Kodi addon: PlexKodiConnect: let Kodi talk to your Plex — Plex ForumsThere's also a LibreELEC fork with Plex Media Player in the works, not sure about how far it's come: GitHub - plexinc/LibreELEC.tv: 'Just enough OS' for Kodi
It's been released as "Plex Embedded" for pi and x86_64 hardware .. available to Plex Pass holders according to the developer folks who work on it. There is also "RasPlex" which continues development of the older PHT client; also rebased/converted to LE.
dos2unix /path/to/fileYou can also do 
that to fix the file.
I'm aware of community builds for S805 (kszaq) and S802 (drieschel) but I didn't see/hear anyone building for S812.
It is technically possible to embed multiple legacy nVidia drivers into the LE image, but this bloats the LE image and is something we have always made a strenuous effort to avoid. From memory ~75% of the cards supported by 304.xx are below GeForce 8xxx which (launched in summer 2007) was the first generation to support VDPAU hardware acceleration, and ~10% of the cards above that threshold still work with the 340.xx driver.
NB: The raid card driver change has been reverted, because if it's only used by one user and that user needs to self-build an image to get old nVidia support, it's another one-line change for the user and we don't need it in the core image.
Over time the definition of "current" and "legacy" needs to move forwards and the decision to bump legacy to 340.xx was deliberated by the team for a long time (we postponed it for 7.0 but agreed on 8.0). The change impacts our support for cards that are typically a decade (or more) old as the newer cards supported by 304.xx are also supported by 340.xx. The decision will stand regardless of your poll and if you are determined to use your ancient card (and need RAID support in the kernel) the solution is to self-build an LE image with the bits you need; as nVidia maintains their drivers aganst new kernels it's a fairly simple change to revert.
If there are a group of users that need 304.xx support the solution is for you to group together and support each other; someone can build an image using the older driver and share it to the group. This is what happened when a group of ION users wanted 340.xx support to solve some graphical images at the time we still used 304.xx. If someone wants to step up/forward as that builder we're quite happy to support the effort with some hosting space to publish the builds from, if that's easier than sharing via dropbox/mega/etc.
Unless your network has some very specific throughput issues (in which case the solution is to fix your bad network) there is really no need to fiddle with the default cache settings and I would always advocate removing custom settings. Also, as active development on Kodi v16 ceased 5+ months ago there will be no video changes in v7.0.3 when it ships - only fixes to drivers and system scripts or similar.
If you have graphical issues it's probably best to experiment with the Krypton-based alpha builds. If you still have the problem there it can be reported (to Kodi devs via their forums) and they can investigate and maybe fix something.
The default behaviour of Kodi is to check at startup, then at a random interval afterwards. It's possible for the initial check to fail if the network is slow starting, but one of the subsequent checks should work. Worst case you can set an autostart.sh script to run in the backround ~2 mins after boot and trigger a check.
The branch is maintained and there will be a v7.0.3 build, but not for a while as there are no urgent/notable fixes since v7.0.2 came out (almost all commits are related to add-ons). Is there something you are expecting to be fixed?
Hi i instaled SuperRepo and mc from repository, but i cant running this from ssh console. Why? Many programs dont work htop mc tar and others...on Openelec is great. Any sugestions?
Official:Forum rules/Banned add-ons - Official Kodi Wiki
I suggest you read the link above, then completely remove supperrepo if you want support in this forum 
There's been no changes since it was first added. It can be made to work as a BT receiver, but it's not suitable for a default config.
official imx6 alpha builds will commence with v7.90.004
It is technically possible to configure a receiving interface LibreELEC but Kodi has no knowledge of the incoming input so there is no on-screen notification and you can end up with BT and Kodi outputing audio at the same time. As a result we support BT audio only as an output device, not to receive.
neither is v7.90.001 or v7.90.002, so I assume you're self-building them?
test again with v7.90.003, and if not resolved test again when v7.90.004 appears (soon-ish)
echo -1 | tee /sys/module/usbcore/parameters/autosuspendRun that and connect the drive. If it works, run this and reboot to make the change persistent:
echo "options usbcore autosuspend=-1" > /storage/.config/modprobe.d/usbcore.confIt's also (maybe) possible to use the value 0 (zero) instead of -1 .. it depends on the kernel used
From a code perspective LE simply consumes whatever upstream Kodi team work on, so we would encourage any DSP related development to be done for the benefit of all Kodi users.
Fast boot isn't usually an issue (unless you acquire something dog slow) but the power-off feature is "suspend" in Android land and getting that to work reliably over a broad selection of Linux devices is a fight we didn't pick yet. It may work on x86 devices which support low-power states, but none of the low-power arm stuff has an equivalent. In the future maybe, but not today.