Posts by chewitt

  • Hardware support.. Why no Nvidia 304.131 moving forward?

    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.

  • Hardware support.. Why no Nvidia 304.131 moving forward?

    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.

  • 7.03 on the Horizon?

    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.

  • auto-update add-ons

    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.

  • 7.03 on the Horizon?

    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?

  • State of Bluetooth Streaming.

    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.

  • serial PROBLEM!!

    Code
    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:

    Code
    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

  • Pivos Xios DS vs LibreElec

    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.

  • Write access on external HDD

    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.