Posts by chewitt

Kodi supports NFS sources similar to SMB sources.

I think you'll get further in the Kodi forums where add-on developers hang out.

You'll need a TTL adapter (normally a USB device) as the signal voltage levels are different to a standard RS232 port. I also see nothing on the board to indicate those are the UART pins, although it's a low resolution image and markings could be on the underside. Normally the +ve pin (pin 1) will have a solid white triangle pointing to it (see the white connector on the left side of the image for an example) or has a white square ring around it - something distinctive. In future please post output to a pastebin site and images to somewhere like imgur - you can share higher resolution images that way.

To fix this you'll need to create an SD card image with u-boot from an A95X-F3 box and then short pins on one of the emmc chips so that the box is forced to search for BL2 firmware on the SD card. If you can get into u-boot (or higher level OS) it's normally possible to zero the emmc (or at least enough of it to resolve the broken boot firmware) and then the box will always boot from SD card and OS installs become easier.

IIRC it works on RPi3 hardware, but their RPi4 version requires/assumes Xorg (for Rasbian) and since we don't use Xorg in our pi images, it doesn't work on RPi4 hardware.

I'm not sure LE has ever supported those accessories, and these days everything involving the legacy 3.14 kernel is a bit of a fading memory and lost cause (it's been consigned to history and forgottten about) so I'm not sure you'll get much help. The Odroid forums would be a better place to trawl old posts for possible info.

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.