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.
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
LE targets HTPC hardware not recycled old laptops whereas Ubuntu targets everything. We have no interest in adding the drivers to support an old laptop with a weak GPU that requires drivers that are known to be problematic. So if it works with Ubuntu .. stick with Ubuntu. Sorry..
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.
Frequent corruption issues are often the result of an inadequate PSU .. the other cause being a card that's on its way out.
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.
Yes, if you use the correct device-tree file.
