Posts by chewitt

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.

"RK3399 needs some catching up and things are known to be a bit broken in the master branch at the moment"

^ this is the English habit of understating things a little to be polite. I'm not expecting RK3399 hardware to boot at all, and I wouldn't bother building images again until a load of pending Rockchip fixes are merged (and no, there is no timescale for this).

RPi v2 cannot boot from USB, it must always boot from SD card (the /storage partition can be relocated to a USB drive but the boot files must be on the SD card). Newer RPi hardware is different; RPi v3 can boot from USB once a config option is toggled in the firmware to enable it. RPi 3B+ firmware supports USB boot without needing the toggle.

Install the multimedia tools addon from the LE repo and then use "alsamixer" from the SSH console to change values.

See https://wiki.ubuntu.com/audio/alsamixer

Update to the 8.90.003 alpha release and retest. Even if we manage to guess what the issue is/was in 8.2.5 it will never be fixed in that release and the alpha codebase is 12+ months newer.