Posts by chewitt

I have the 65" version of the same LG panel and a similar AVR and a legion of test boxes/devices to experiment with. The short answer to the question is "the box you are seeking does not exist" .. and on that basis I'd go pick up a cheap S905D box with GB ethernet (avoid the S905D devices with 100-BaseT PHYs). It'll be fairly cheap so when you chuck it out in 24 months time to get a newer (still not meeting that spec, but more advanced in some way) device you're not left writhing in angst about how much it cost you.

NB: Nothing truly supports HDR on Linux right now, but Amlogic is the leading "least worst" option at the current moment

The LE staff have a generally low opinion on Realtek wireless devices. The hardware is probably reasonable, and performance on Windows is probably great because that's where they invest all the Engineering time. Their Linux drivers are an afterthought, and we're fed up with they way they breed chipsets and new drivers that rehash the same greatest-hits compilation of hacks over and over.

Find something that uses the ath9k driver, which is in-kernel and much higher quality code.

The moral of your story is buy a USB wireless dongle that has a decent chipset and in-kernel driver, not some piece of realtek crap.

LibreELEC is intended for dedicated HTPC devices so Kodi (on LibreELEC) runs full-screen and outputs to the primary display device (whatever that is) and there is no GUI support for running with multiple-monitors (or laptop screen + HDMI output). It can be done from the command line, but that's more advanced. Another option for a laptop could be forcing the display output in the BIOS.

If you want GUI multi-monitor support, use Windows or a conventional distro like Ubuntu.

Which kernel? .. DS1307 has been enabled in our Raspberry Pi kernel config since 2013.

RPi.GPIO is part of the "RPi Tools" addon in our repo and should work exactly the same way (the wheel wasn't reinvented).

Update to the current 8.90.003 alpha which has newer drivers (newer everything) and retest.

It's hard to comment without knowing what hardware you have, which driver that unknown hardware is trying to use, and which OE/LE versions you're comparing?

Sorry I thought you were trying to play media using Kodi. Chrome runs outside Kodi (in the OS core) and nothing is logged. Most issues are down to the media being played being 1080p and requiring hardware decoding; and hardware decode not working. What does Chrome show for those settings?

Amlogic hardware isn't the best with 3D media (AFAIK not all 3D formats are supported) and an S905X device will struggle with full-size ISO rips due to the 100Base-T ethernet port being slow for the large size of media files. Raspberry Pi 3B+ has GB ethernet (not full speed to the internal USB 2.0 bus but good enough) and the best 3D playback support of any Kodi device; the Pi Foundation staff put a lot of effort into their (pi only) hardware decoders.

It's not a debug log (so is missing half the info i'd be interested in) and it shows you have piracy repo's installed. No further support will be provided until you post the correct log from a clean box.

Have you experimented with setting the output configuration to "fixed" and then limiting the sampling rate to 44.1 KHz?

You can extract and write with dd if you like. Or you can also use our USB/SD creator app which handles .img.gz files without needing the unzip.

Time and people not being on vacation will move things forwards. No promises on when though.

At the current time there is still no clear forward path for Kodi support on a mainline kernel (which is required to use Maxime's open-source V4L2 decoder) for S912 hardware. Future options (listed in order of probability and time) might include:

a) Using the swrast mesa driver to provide a fake software OpenGL environment. This is something we'll test soon (once developers stop being on vacation) but Kodi makes extensive use of GL animations in the GUI which will need lots of CPU to recreate and the S912 probably doesn't have the grunt needed. Disabling animations in the skin might help, and even if the GUI isn't perfect actual video can still be hardware decoded so playback should be okay (OSD performance issues are likely though). Armbian has done some experiments with software rendering under X11 (which is not a technical direction LE is interested in pursuing) that give an idea on performance.

b) Using libhybris (as the 3.14 kernel does). This approach could still work, but libybris needs to have Android kernel support that's broadly equivalent to the Linux kernel you're running and Android 8.0 support in libhybris is still in early stages. Android 8.0 uses an entirely new hwcomposer API for rendering and support for that needs all-new code and progress on this appears to be slow.

c) Using the panfrost open-source reverse engineered alternative to mali blobs. We've been tracking panfrost for a while and the lead developers are aware of LibreELEC and that we'd love to use it with Kodi to solve the lack of native libs. The main developers have some RK3399 hardware that uses T860 which is in the same family to the T820 used by Amlogic, but little time to work on support at the current time due to a range of other personal commitments. If and when there's some panfrost code to poke in the future, we'll be all over it.

In summary: unless Amlogic has a sudden change of heart on licensing (which is extremely unlikely based on past and recent conversations with management people and some knowledge of the $$ sums involved) the best-case scenario for S912 in the foreseeable future will be some kind of compromise. Our advice is still that people should avoid purchases of S912 hardware because there's a ton of "maybe" and zero guarantees in the above ideas.

edit /flash/cmdline.txt and set disk=/dev/sda1 where /dev/sda1 is an ext4 formatted USB drive

Quote from doggyofone

Coreelec is now on beta 8.95.0, Beta 1.

That's because their developers don't understand how Kodi tags releases. The splash images and internal versioning might have been bumped in preparation for a v18-beta1 release, but until the beta1 tag (and release branch) exist v18 remains in alpha.