Posts by chewitt

1. RPi4 supports hardware decode of 4K HEVC, but not 4K VP9, and not H264 (which is not a standard).

3. The TV should support a "Just scan" or auto mode. On a modern TV you should never need to calibrate the screen. And 1080p@60 is the best default resolution. Forcing the screen to run at 4K just adds load to the device. Kodi is already upscaling the 720p skin to 1080p, the TV will do a better job of scaling 1080p > 4K (native resolution of the panel) can Kodi does scaling 720p > 4k.

4. The filesystem is read-only apart from the persistent /storage area - this cannot be changed Anything you need to configure can normally be done in /storage, but we can't advise what to do unless you explain what you're trying to change.

5. Resolution determines the GUI (desktop) resolution. The whitelist determines the resolution/refresh rates to be used for playback if "adjust refresh rate to match video" is enabled. If the TV supports them, enable [email protected]/24/50/59.94/60 and [email protected]/24/25/29.95/30 (50/60 optional).

6. It generates more heat and draws more power, and IMHO is completely unnecessary unless you actually have 4K60 media. So far I've only seen test media in this format so I don't have it enabled.

Quote from maildjain

seems like 9.2.2 rewrites the boot-loader ? Can anyone help please ?

Once installed, nothing touches the bootloader.

I already have support for the C4 in my private git repo, but I need to clean some things related to Linux 5.7 up a little before I push support to the LE repo. Adding support for the C4 took a whole 30 mins as Dongjin had already prepared a device-tree file for Linux 5.4 that only needed a couple of minor updates for Linux 5.7 - and the device-tree is now submitted upstream.

To answer the original Q more directly. During playback press the 'o' key and it will show you whether FFmeg hardware or (SW) softtware decoding is being used. Older Intel low-end GMA chipsets are not always so well supported, they pre-date the point where Intel got properly interested in Linux and started to invest effort in support (in the newer hardware that followed). You might find that Windows is a better option.

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.