Posts by chewitt

The original error is caused by the kernel boot= param being wrong or (more likely confused) so it fails to mount the partition with the SYSTEM file and dumps you into the initramfs debug shell (which is pretty limited). If you're installing this doesn't make sense because the entire install process runs within the initramfs environment (in the KERNEL file) and you never reach the point in the boot process where SYSTEM would be required.

So I think the USB bootloader is finding boot params on the SSD (for normal boot) but then you have some kind of disk label clash that results in it failing to find the SYSTEM file and boot fails. If you already made a backup of the existing system and exported that off-box for safe keeping, boot from an Ubuntu LiveUSB and reformat the SSD (any format is okay) then try to reinstall.

Netflix is currently broken .. some changes on the Netflix end that will require the addon to be adapted.

It will not work on LE 8.2 due to missing crypto support.

For Android problems you need to post in the Kodi forums, it's not our area of expertise.

Milhouse builds were required in the LE 8.2 era. Current Alpha releases run those addons fine.

It also crashes in High Sierra and possibly older versions of the OS too. I believe Apple has changed something with respect to app Sandboxing in their latest security update as even disabling GateKeeper (which has been reactivated despite me previously disabling it) doesn't permit the app to work as it did before. We will investigate, but that will take time so for now you will need to use another app. Etcher works well.

Quote from RayW

using as I do BS Streams

^ pirate stream crapware; all future support will be refused pending proof of a clean system.

Nope. The mali T820 GPU in the S912 is has a completely different architecture to the mali M450. Another project (panfrost) is working on support but that is some way off yet. We've managed to render bits of the Kodi GUI with panfrost, but not all of the bits simultaneously

Some teamwork this afternoon resulted in LE running "lima" for the first time

Definitely some rough edges to polish before we can consider using it in releases, but having testable code is a good start. It's not shown in the images but this was running on an S905X board.

I'm interpreting the request as 100+ man-hours of fiddling around with underused staging code to create something complex that will be a pain in the rear to support considering the average skill level of our userbase. The alternative is searching eBay for a wireless basestation that can share printers over a network. The last Apple Alrport Express I acquired for exactly this purpose was £12 including postage. If you're retired and/or have nothing better to do with your time .. feel free to experiment. If you're not and you value your time .. use the right tools for the job!

What channel do you run your WiFi network on?

It rather depends on where you are in the world. In a number of EU countries there are popular satellite and terrestrial broadcast channels (even HD ones) that use interlacing so it's important for people using Kodi's DVB capabilities.

Using an RPi as the back-end should be fine.

It's often a one-line simple change but that's never been the point. There are specific long-standing exceptions which are about technical focus for the project (e.g. no RAID support) but as a broad rule if things have provable benefit we will consider adding them.

LE is using tar from busybox not the full GNU tar binary so there are limitations in what tar options are covered - and that specific archive is using something that isn't supported. If you gunzip the file first then untar is shows "tar: invalid tar magic" when trying to expand the archive. You'll need to download and uncompress the archive somewhere else then move the files over. If you're doing it frequently you can probably copy the GNU tar binary over from another distro (as long as it's compiled for the same CPU/arch things usually work) and use that instead.

S905X2 supports Dynamic HDR10, HDR10, HLG and Technicolor HDR. It's all rather irrelevant though because right now the mainline Linux kernel doesn't support HDR and Kodi is only just adding the first wave of support for all the colourspace, decoding and rendering combinations required. We are in contact with the Intel developers who are planning to submit the initial patches for HDR support soon. Once that patch-set lands and clears initial maintainer reviews we can start work on adapting the new Amlogic DRM driver to the same kernel frameworks and finish integration with Kodi. This means it will not be until K19 that Kodi (on Linux) truly handles HDR and other new formats correctly. Until then support is a string and duct-tape job based on educated guesses about how the as-yet undefined upstream kernel stuff will look like. The older 3.14/4.9 kernels + amcodec are similar (but with different bugs) due to HDR support being added long before there was any kind of standard to follow. In both cases the result is something that "works" but has numerous gaps.

We don't add kernel config on the random hope it does something - but you're welcome to self-build an image with changes and experiment and prove the change achieves something beneficial.

One of the current gaps on mainline code is software-only deinterlacing. It's watchable for most programming but sports with lots of fast panning shots have bad combing. I keep a spare box on 8.2.5 for watching F1 and MotoGP coverage

Netflix is software decoded on all Linux hardware (the addon mimics a browser with an L3 widevine cert) so max resolution etc. will be constrained by hardware CPU performance. There is no way to use the L1 certs embedded in some boxes from Linux because we're a generic distribution and the secure boot code required is both closed-source and device-specific.

Maxime and I did a mountain of testing since ~June so the 8-bit side of his code is in great shape, but there are still milestones to achieve. The DRM driver that underpins everything is missing 10-bit capabilities so we're unable to fully test the HEVC parser code in the vdec and Maxime is still working on seeking (which is more about Kodi and ffmpeg than his vdec). There is currently no hardware deinterlace code (only software which is watchable but not brilliant) and we still need to persuade that and VP9 support into existence. On the positive, we have HDMI 1.4 (up to 4k30) working - although only for 2GB+ boards as Amlogic's alternative to AFBC isn't supported in the DRM driver yet so we're using too much RAM. The mainline kernel is also missing HDR support, but based on recent email exchanges with Intel staff we'll see some movement on that soon and we'll be able to hook into the same kernel frameworks. Kodi is also seeing some love in that area so at some point between K18 and K19 you'll be able to watch an HDR movie without having to force the colourspace and other dumb crap that doesn't work in older 3.14 kernel releases. We're also missing multi-channel audio support but the same Synopsys audio IP is used in a broad ranges of Amlogic, Allwinner and Rockchip hardware so there's a plan to pool efforts and collectively solve that at some point.

So right now if you only want 1080p or 4k 8-bit video + stereo audio it's pretty stable and usable. I'm not planning to start major public testing until after 9.0 ships and a few more pieces of the jigsaw come together - largely because I don't have the bandwidth for needy users and the support work that releases entail. I'm not sure if we'll jump to using lima immediately - it's not perfect yet (as that video shows) but that will come with time and love. NB: There's also been recent progress on the lowest-level boot code (ATF etc.) which is the final layer of closed-source Amlogic code to tackle. If that work completes it's indeed plausible that 2019 might see GXBB/GXL boards running a 100% open stack, which would be awesome and frankly rather amazing considering where things were a year ago.