Posts by chewitt

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?

Quote from ozmatox

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/autosuspend

Run 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.conf

It'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.

The clue was "GeForce" .. which means it's an older card.

x11vnc requires the Xorg/X11 graphics server which does not exist in Amlogic builds; only in Generic (x86)

Reconnect the NTFS drive to a Windows box and run chkdsk.exe, then disconnect correctly to ensure the filesystem is "clean" because if the filesystem is not clean Linux will mount the drive read-only ~ and that would explain why nothing can be copied to the drive over the network.

Just a comment: That nvidia 7 series GPU will be unsupported in LE 8.0 as we bumped the "legacy" driver version to something newer.

The clue is in the im6/xbian name .. the origins of that Kernel are not OE/LE so there will be a few differences. It's trivial to add the module, but does the device also require firmware?