Posts by chewitt

    Lima woke from slumber about 4-5 months ago and started showing progress and we've been engaged with Yuq since - the video you've posted was created this morning by LibreELEC team member koenkooi and an equivalent LE image is my task this evening. We've also been engaged with the panfrost developers for some time and recently persuaded a couple of them to accept S912 boards so development can be done on a modern mainline kernel instead of Chromebooks that require an ageing Rockchip 4.4 codebase. We are being our usual helpful and supportive selves and Kodi support is seen as a worthwhile panfrost objective. I'm confident panfrost will be the missing piece of the long-term jigsaw puzzle we need for S912 support, but things are still at an early stage and it will be some time before panfrost code is in a mature state that's sensible to use (we did get it to show bits of the Kodi GUI tho!). I'd guess another six months is needed - the midgard/bifrost chips are mind-bogglingly more complicated (and completely different) compared to the older utgdard chips.

    These chips are not supported on our current codebase and require the Amlogic 4.9 kernel which is not fantastic - the quality of Amlogic's botch job proprietary code has not improved and the overall kernel has become more Android oriented with time. Also, S905X2 does not guarantee GB ethernet (lots of boxes will use a 10/100 PHY) and while the Mali G31 is more capable than older Mali GPU's the performance increase is largely lost on a simple app like Kodi where rendering is capped at GLES 2.0 anyway.

    So the forward path isn't clear yet. For some time our development focus has been on moving away from bug-ridden old kernels and onto a modern codebase, but while Amlogic have been sending patches for G12A platform support to the kernel for a while it's still in an early state and mainline kernel LE images for these boards are not currently possible (i've had hardware for a while). The 4.9 kernel also has a crop of new bugs to find and fix (in addition to loads of unresolved old ones inherited from the 3.14 codebase) and ultimately it depends on amcodec support which exists today but will be removed in Kodi v19 - so it's a load of work with a limited lifespan.

    IMHO these devices should stick to Android until mainline kernels are viable, but I daresay users will be pissy with that suggestion and someone on the team will be forced to grapple with the 4.9 kernel mess as a stop-gap. It won't be me though :)

    1. Would you recommend I stay with the AML platform (S912) and wait or swap to another platform like Allwinner or Rockchip?

    2. As the main usage of these boxes is to stream video, and the issue I have described is related to streaming, why are AML products being recommended when this bug clearly interferes with the boxes main purpose? Sorry, but I just don't get it ?(

    Allwinner support is in the earliest of early stages of support. It will be some time before it matures. Rockchip is further up the curve but still subject to major rework before we publish a full release. Rockchip is both better and not as proven as the Amlogic 3.14 mess (which has been used long and is a bit more refined). If you already have the S912 box; it's a good box, be patient.

    As a general rule Amlogic behaves well with most media. There's always going to be some exceptions though. If anyone else wants to investigate I won't stop them - it won't be me though.

    LE has always required a formatted target. The installer script uses the "blkid" command to identify potential install targets and blkid won't show anything unless the storage has been formatted with a filesystem first. It doesn't matter what filesystem is used, only that there is one.

    If you attach a USB keyboard you should be able to run commands. It's attempting to follow the boot=UUID=UUID-5BE6-0135 param to mount /flash and the SYSTEM file to continue booting. The UUID is presumably wrong and boot params in extlinux.conf need to be corrected.

    The main issue with current Amlogic hardware is low-quality kernel source full of bugs and proprietary code and the amcodec interface which has lots of hacks to workaround the bad kernel source. We've cleaned up some major issues over time but there are lots of minor ones that aren't resolved - and won't be resolved (on that codebase). The long-term solution for Amlogic hardware is to move up to mainline kernels. This won't be a magic cure-all (new code = new bugs) but since the underlying codebase will be common to all our platforms (Generic, Raspberry Pi, Amlogic, Allwinner and Rockchip) the process of fixing stuff will no longer depend on someone working up the enthusiasm to poke sticks at a bad kernel source where fixing one thing frequently results in fresh breakage somewhere else. We are months (not years) from making the mainline jump.

    NB: I wouldn't read too much into the S912 future story as the situation has changed. Open-source alternatives to the missing libmali are taking shape, we are well engaged with the developers and Kodi support is a mutual goal. I'd estimate we're about six months from a usable solution.

    You can ignore the false warning (because os.libreelec.tv is installed) and continue or wait until the next Alpha release is out where we've added a temporary patch to prevent the warning - pending Team Kodi doing something to properly fix the issue.

    Anyway, thanks to you (and all the other active developers) for making it possible for users like me to play with our toys! I do hope that you also profit from donations made to LibreELEC :angel:

    We profit from the personal experience of participating in the project and having fun, but otherwise we are non-commercial and aim to raise no more funds than we need to cover the project's running costs.

    Nope, because decoding and rendering are separate things. Even if FFmpeg supports NVDEC for decoding we still need to render the decoded video via a zero-copy code-path and this is where the issue lies. Kodi supports GBM and nVidia's driver supports a competing "standard" (used only by nVidia) called EGL Streams. So Kodi will need to add another vendor-specific code path just for nVidia. The two logical candidates to do that within Team Kodi are lrusak (who wrote the GBM code) and the main architect fertnetmenta (who maintains VideoPlayer) and so far neither of them are interested.

    Could be a while. Our efforts with the RK 4.4 kernel codebase have been a stop-gap until VPU support for the mainline kernel was available and the changes to add this now been submitted so we've started the lengthy process of rebasing against Linux 4.19 - which means no more real-world effort against the 4.4 codebase.

    NB: Next 9.0 Alpha will come out with changes to Kodi but nothing much more. We have no plans to release Rockchip Beta or full release LE 9.0 images - Rockchip will remain in an Alpha state until at least LE 9.2.

    The StiH206 chipset does not support OpenGL or OpenGLES so it cannot run Kodi. Even if that wasn't a showstopper it wouldn't be worthwhile when a Raspberry Pi Zero (costing $6) has a higher spec and is better supported.

    It should be supportable, and if they care about good Linux support for their product they will submit a device tree file to the upstream kernel. If you don't see any submission .. they're just another clone vendor who expects "the community" to do all the leg-work for them.