Posts by chewitt

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.

obexd is completely missing in 8.90.003 but the fix was already committed so it should be resolved in the next release

Maxime is an independent developer (not working for Bootlin) and we've been helping him find bugs in the decoder for 4-5 months already and as part of our long-term effort to bring Amlogic into the modern world with a mainline Linux kernel partnered with the next-generation Kodi (on Linux) video pipeline.

It won't make any difference to CPU consumption because it's a hardware (not software) decoder. I'm not aware of CPU usage being an issue with Amlogic hardware; other than some Amlogic SoC's being cost engineered and a little slower and weaker than others.

Developer focus has been on RK3328/3268 for a while and RK3399 needs some catching up and things are known to be a bit broken in the master branch at the moment. Not sure why the file is truncated at 21MB but we'll get that cleared.

Can you share "lspci" output.

what does "bluetoothctl" show?

It looks like the kernel finds the BT device and loads firmware. If this is a clean install did you enable the BT service?