Posts by chewitt

mo123 the Manjaro folks claim to have packaged widevine now - I pointed a couple of their devs to the Kodi inputstream.helper add-on and they've basically copied the same "download chromeos, extract files" process.

stpf99 there is commonality around the stream transport layer, e.g. HLS, DASH, hence things like inputstream.adaptive exist in the Kodi repo that will be used by many add-ons, but the content/catalogue mechanism is typically site-specific and each portal/site rolls their own API framework for access.

scarface911 If the flashing via Amlogic Burning Tool gets further than 10% complete the emmc likely has enough of the Android image installed to have restored vendor u-boot, and from that point you should be able to use the AMLG12 image with SEI610 or VIM3L device-trees - both are S905X3 devices, or maybe even the U200 or X96-max devices trees (set the dtb name in uEnv.ini). If not, I'd need to see debug UART output from the box to understand what the issue is - else it's a blind guessing exercise and I'd rather not start that.

Not going to work because:

a) We don't ship any 32-bit (i386) OS since 2015

b) Device has 50% less RAM than the lowest/worst spec device we ever supported (mk1 AppleTV)

c) Even if you figured out a custom image to deal with A and B, the GPU probably isn't supported

Find a second-hand Raspberry Pi 3B+ on eBay (lots of people upgrading to RPi4 means there are lots of cheap ones) and it will be a better investment of time and effort.

Hard to tell as the log is mostly garbage, but try deleting /storage/.kodi/userdata/profiles.xml and restarting.

There is basically no upstream support for Meson 8 in u-boot right now, and while some bits of GXBB support might also be reusaable I'm not aware of any plans for someone to look at it. Plus you still have to contend with design mistake on all pre-GXL Amlogic SoCs where boot firmware needs to run in the first sector of eMMC which means you can't use normal partition tables.

The issue has been raised a couple of times. I've flagged it to the connman developers. We have to see what they say..

I'd guess the Marketing people said "make Steamlink work on a Raspberry Pi" so the Engineering people looked at what Raspbian needs and made it work on a Raspberry Pi. If you've ever worked for a large technology company this kind of stupid is defacto normal.

I would see if it's possible to change the primary display device in the BIOS to use HDMI1 not LVDS1 (broken screen). It may also be possible to toggle the output using F7 keys or such - if the toggle is done in hardware not software.

/usr/lib/kodi/kodi-xrandr <= gives modes available to xbmc

xrandr --output HDMI-0 --mode 0x1be <= sets the 0x1be mode on HDMI-0 using the mode shortcode

it might also be possible to use a custom xorg.conf to force the output to HDMI, but it's no long since I fiddled with Xorg things I'm hazy on how that's actually achieved. NB: Raspberry Pi boards make much better HTPCs than recycled old/broken laptops.

There's an add-on in the Kodi repo desgined to help people switch screens off .. I forget the name but the author is dagweirs.

amlogic: add experimental AMLMX device · chewitt/LibreELEC.tv@1684aaf · GitHub

^ this is the minimum. Odroid C1 needs a bootable image so I'm still experimenting with the least-worst way to combine prehistoric pre-built u-boot and our more mainline u-boot oriented build-system so those bits are not in any of my branches yet.

I'm fuzzy on the details, but ISTR some internal conversation/moaning about the close-source bits of steamlink being compiled with dependencies on pi-specific libs that don't exist on other devices, or something similar..

If you delete /storage/.cache/connman it should remove all traces of previous network config, although I don't see what the issue could be.

Look at your webserver logs and you can see the actual URL being requested. The common mistake is configuring http://your.host/releases.json when all you need to do is configure the hostname, the releases.json will be appended by the settings add-on.

It would have to stop Kodi because there is no way for it to run within Kodi.

As a general rule we're happy to backport useful patches that have been submitted (and merged) upstream, but we prefer to minimise the number of local patches that haven't been submitted. So, it's really a case where if someone made some useful patches, they should submit them to the rockchip mailing list and get them added. Sending stuff upstream is not particularly hard..

LE does not need swap, which is why it's not enabled by default in any of our images.

Odroid C1 is an arm (32-bit) device. Odroid C2 is an arm64 device. You need to do more than simply change the kernel source, i.e. define a device with an arm(32) defconfig and CPU params.