Posts by chewitt

  • [Solved] LibreElec test Build HOW TO

    Quote from madhits


    Not to totally dog you or chwett but this process has to be made a lil easier if you want more people involved. I get the sense that you and chewett dont want any new devs. I hope my feeling is way off. Making some scripts up and posting them may help a lot of people get into this. I have always learned by looking at the answer and working backwards, maybe that is why scripting is something I get.

    Oh, we would love more developers, but proper developers typically take a quick look at our very logical buildsystem and crack on with the thing they wanted to do. People who are not developers are the ones who struggle with the process. To be brutally honest, if people haven't got developer skills they are not the developers we want to attract.

    First thing to do is create a completely stock version of LE with no changes following the instructions in the wiki. This proves the build-system works (which it does, I build images using it every day). Once you have a working stock image, there are two one-line changes to make (kernel things) and maybe one patch to find (for 304.131 on 4.7 kernel) and the work is done. No need for scripts.

  • Black screen on launching video

    I'd recommend experimenting with the current alpha builds for two reasons: a) there are significant changes that affect Intel since Helix (OE 6.0.x) and there's a chance the issue is already resolved, and b) Kodi devs moved all development to Krypton now, so if something is broken on Jarvis it will never be fixed, but on Krypton it can be reported and Kodi devs will investigate (and hopefully fix) the problem.

  • Access Plex Media Server

    Quote from escalade


    There's this Kodi addon: PlexKodiConnect: let Kodi talk to your Plex — Plex Forums

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

  • 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.