I don't create Pull requests for AIC8800 driver because I agree with chewitt and LibreELEC perspective.
Yasai-san Just create a pull-request with "This PR is being submitted so information on how to add the AIC8800 driver package into a self-built image is more easily found. I support the project's wish to not add downstream drivers that have no visibility of being upstreamed and do not expect this to be merged" .. so we look less authoritarian when we close it without merging 
It is not impossible to create/build mainline u-boot for eMMC install on Android TV box hardware, but this requires the original BL2 (and BL301) sources for the specific hardware (tweaked by the manufacturer for the out-of-spec low-bin RAM chips used in specific batches of boxes) which you don't have. It is also not impossible to reverse engineer boot firmware to extract the pre-compiled bits, but this requires the original Android ROM which you don't have. That task also requires tools/skills most users lack, and a level of repetitive "puling your teeth out" time and effort of that project staff have learned to avoid, and this is why none of the distros that you mentioned are interested in supporting eMMC install on Android boxes; except in a few rare cases where the original sources are available and the outcome is reliable.
You might have greater success in sourceing ROM images or find a more willing audience in Android supporting forums.
The Allwinner image supports overlays so you can probably just drop the existing dtbo file onto the SD card and modify the extlinux.conf to use it; LE and Armbian should be similar in how that’s done as they both use mainline u-boot.
Or you need to compile an LE image with a kernel patch to add the overlay so it will be compiled and added to the image. Or you submit the patch to our GitHub repository so it’s merged and added to the image; although we mostly refuse patches that are not also submitted to kernel mailing lists (we want to know the patch is good and will be dropped in the future when the fix is upstream).
you just need to run this command again because someone has already received the same link before.
Correct.
Running the Kodi GUI at 4K resolutions (as per the other issue thread) probably doesn't help the GUI responsiveness. I wouldn't be suprised if running things at 1080p improves the remote situation?
The Linux end of things is probably trying to use a 4K mode the TV doesn't like. Append video=HDMI-A-1:1920x1080M@60D to the line of boot params in cmdline.txt on the SD card and reboot. That forces the intial DRM state to 1080@60 which should avoid the issue, and you want to be using 1080p for the Kodi desktop anyway (unless you want a slow GUI experience).
The lack of info in kodi.log proves Kodi didn't do/signal anything so the issue is either something in the Linux kernel/DRM layer or perhaps (as suggested) something related to the TV itself.
Is there anything in the system log (dmesg)?
Manufacturers who make hardware constantly add features to "improve" output, both to improve the viewing experience, but also to ensure the marketing department has something to support claims of their device giving the best experience. Some viewers claim these features do improve their experience and <insert_name_of_latest_device> is the best thing invented since sliced bread. Others seek to watch movies "as the director intended" and claim the same features detract from the experience. Reddit provides a free service to fuel all sides of the "what device/distro/player-app/settings works best" debate by selling advertising placement to the marketing departments of manufacturers and retailers.
IMHO dedicated BR/DVD/SACD/CD hardware usually gives the best result. However my kids destroy BR/DVD disks by leaving them wrong-side-down on the floor and never place watched things in the correct box, so I still rip everything and accept the lossy format conversion to mitigate those problems. I use general purpose settings when ripping. I do occasionally re-rip with tweaked settings if the results aren't so great. I still choose to watch certain films on proper hardware sometimes. The amount of 4K/UHD media that I purchase and rip vs. stream from a subscription service (media reformatted to suit streaming and look okay on more devices) or record from a broadcast (media reformatted to squeeze into broadcast constraints) continues to decline though.
Two comments:
a) It's not unheard of for Android boxes to hard-code CPU identifiers in their software so that less scrupulous manufacturers can pass off older or cheaper SoC chips for something more expensive, or even chips from a completely different SoC vendor, if that helps to sell more boxes and/or clear stock. Hence you might find different SoC chips being reported in different places. The best way to check what's physically inside the box is to open it and literally see what's under the heatsink (if one is present). NB: Even that's not infallible, as we've also seen chips silk-screen reprinted to hide what they are, but that's not common.
b) There is currently a single LE image for an RK3328 based Android box, the "a1" image. If this works, great. If not, there are no plans to add more images for Android set-top boxes. As a general rule, trying to support them is a challenge. Boxes are typically based on reference designs so there is enough in-common to easily boot an image, but booting is no guarantee of reliability and there is enough variation in designs (combined with selection of cheap low-bin components) to ensure reliability always remains slightly beyond reach; whether that's due to electrical or thermal or other reasons.
It would be useful to see a Kodi debug log from one of the devices when trying to open the add-on.
Is maybe some memory/cache running out of space?!
Unlikely to be memory/cache related (and not a direction we'd look in). Please upload the whole file to Google drive and email a private link to chewitt@ our domain. I'll confirm Pi devs have it downloaded so you can delete the file/share after.
I've read on reddit that playing HDR content directly with LG native player produce better quality, how ?
Upstream Linux supports static formats like HDR and HDR10, not dynamic formats like HDR10+ and DV, so other player apps running on other OS e.g. Android with vendor kernel that includes magic closed-source binaries for DV support, or a good physical media Blu-ray player that similarly supports dynamic HDR types; should/could in theory give better results than e.g. LE running on an old NUC that does not.
Also what is the difference of using this NUC to play a 4K UHD BD Remux in HDR and using a good bluray player like panasonic UB820 with same UHD media but on physical disk ?
Some users will insist they can absolutely tell the difference and there is a multi-billion dollar industry designed to relieve them of $$ in the pursuit of "bit perfect" quality. That said, the entire concept of "bit-perfect" doesn't exist for video due to how original media encodes a suggestion of how to show things that is then interpreted by an imperfect display device, e.g. no TV in the market actually supports 10,000 nits brightness, so even if the source media is perfect the output that you see is always some kind of best-efforts compromise.
Ripping media to anything other than ISO results in format conversion and this is always a lossy process. Most users are happy with some quality loss for the convenience of having their media in a software format, and with HEVC and AV1 offering smaller filesizes than H264 and particularly ISO, for a "perceptually similar" level of quality, most users are happy to avoid the need for many TB of HDD space. I do find it amusing that the "bit-perfect" crowd found on Reddit and Android forums espouse on how perfect their system is when logs show their source media to be some remux torrent with totally unknown encoding.
Most users are just happy with the HDR logo lights up and the display and colours are brighter and things generally look better than a boring old SDR movie. Most users over the age of 40-years are also subject to some level of macular degeneration.
"Don't believe everything you read on the Internet" -- Abraham Lincoln
The [email protected] issue is seen with pass-through audio; thus Kodi cannot resample the audio stream else you defeat the entire point of passing-through the untouched audio stream to the next device in the HDMI chain.
The correct behaviour is to reduce the video bit-depth from 12-bit to 10-bit so there is enough bandwidth for audio. Intel devs will desire this to be dynamic so the driver maximises bit-depth unless it needs to step quality down. This is more for desktop distros where the bit-depth quality of the desktop is viewed as important. It's less of a concern for LE as no broadcast media uses 12-bit depth; only some Animé content with special (non-standard) encoding so we're fine with 10-bit max. If the Intel devs come up with usable patches (or at least show serious signs of upstreaming a proper solution) I'll be prepared to accept a temporary hack patch that caps the driver at 10-bit. If there's no sign of being able to drop the patch in the future, that's not an option.
the following command doesn't work: ssh [email protected]
The response to the latest post I made to the Intel bug tracker thread was positive and shows people are a) still employed and doing driver development work, b) now accepting the strong correlation between bit-depth and bandwidth consumption being a big hint on the problem. Hopefully the patches they've linked in the thread get cleaned-up 'soon' so we can test them.
If you write LE13 on the eMMC, it is not guaranteed that you will be able to boot older versions.
The Amlogic vendor kernel has some drivers that assume an era-appropriate vendor u-boot is installed so it can probably be done with a little manual fiddling (which there are no guides for) to fix wrong-named boot files, but I guarantee that some drivers don't work right, and as the maintainer of the AMLGX image; this is not something we have any interest in trying to support.
Well done developers, I really like what you have done.
Credit is more likely due to Tvheadend devs or Kodi pvr.hts devs. All we do is bump the add-on as updates are pushed
