Posts by chewitt

scarface911 this endless loop is BL1 (hard-coded into the SoC) searching for BL2 firmware. It is actually a better (more simple to work from) position than having the wrong or broken firmware installed, as we can experiment with booting from an SD card.

Write the images below to an SD card and pastebin the UART output so we can see what happens, both C4/VIM3L are SM1 devices:

LibreELEC-AMLG12.arm-9.80.0-khadas-vim3l.img.gz

LibreELEC-AMLG12.arm-9.80.0-odroid-c4.img.gz

If any of them boot (u-boot) but fail to run the kernel, download the AMLG12 "box" image from the same location and steal the SEI610 device-tree from it (change the dtb name in extlinux.conf) as I've had one person report that it works (mostly) with an A95X-F3 device.

C2 (GXBB) has a different u-boot signing process to an S912 (GXM) device, but in terms of how the signed u-boot is written to a bootable SD card (or emmc module) it's the same. See:

LibreELEC.tv/mkimage at master · LibreELEC/LibreELEC.tv · GitHub

and

LibreELEC.tv/install at master · LibreELEC/LibreELEC.tv · GitHub (C2)

LibreELEC.tv/install at master · LibreELEC/LibreELEC.tv · GitHub (GXM)

LE does not support this chip.

If Android starts failing to boot and reflashing is also failing there are probably defects in the emmc storage, but if you're able to boot a 3.14 image from USB the factory u-boot is still intact. Before attempting anything else I would use the USB booting OS to make a backup of the first 8MB of the emmc so that you have a copy of that u-boot, because although it's fairly simple to build bootable images for GXM devices, if the box has extra-cheap emmc chips (not unheard of) the fip sources might have been tweaked with custom timings (to deal with out-of-spec chips) and then it's unlikely you'll be able to find or recreate a bootable image. If the emmc deteriorates further it's then possible to erase emmc (short pins to boot from an SD card with factory u-boot installed). Worst case you might end up in a scenario where you need to boot from u-boot on a SD card but run an OS on a USB stick.

NB: Once you start fiddling with boot firmware and u-boot it becomes important to have a USB > UART cable to see the boot/console output. If we can see that output we can literally see where things break and what happens when we experiment. If we can't see that output, we're reduced to guessing where the issue lies.

I have no plans or interest in resurrecting work on AppleTV boxes. I still have the OE branches in my GitHub repo so if you wanted to attempt the backport you could. Use an older Ubuntu image to build with, 16.04 should align with what I/we were using at the time.

I'd guess that the stream starts, but over time the buffer drains and then once it's depleted we have to re-request chunks of media to fill the cache again and the seeking behaviour to refind the start point to recover the stream generates a load of traffic. TL/DR; WiFi sucks. If you run an Ethernet cable the problem will probably go away. If that's not possible sometimes the better alternative to a USB device is an Ethernet > Wireless bridge. I'm personally a fan of old(er) Apple A1rport Express devices used as bridge devices as they're small and generally give good reception.

Restore needs approx 2.5x the size of the backup free on /storage for the restore to work. If I were you I would start with a clean install, then restore the older sources.xml and DB files (deleting the current/new ones). All the skins/add-ons and such from an LE7 install will need to be upgraded to work on LE9.2 anyway so it will be easier and faster to start over with a clean system.

The correct path is always /storage/.kodi/temp/kodi.log .. just start the tail, then start the library scan, and when Kodi crashes the output will stop at the point where it crashes. Use a large scroll-back buffer in Terminal.app or PuTTY (or whatever SSH client you use) and the copy/paste to pastebin and share the log. You cannot stop the tail and use the built-in paste, as by this point Kodi has probably restarted which will generate a new log file.

Your TV will do a better job of upscaling a 1080p GUI signal to the native resolution of the TV panel (4K) than Kodi will achieve rescaling a 720p or 1080p skin to the same size. Also, unless you have 4K60 media (most people don't) there is not much point forcing the board to support more than 4K30 resolution; it only increases the power draw and heat output of the board. You can still set the whitelist to allow 4K resolutions and Kodi will switch to them when you play 4K media, but then return to the 1080@60 GUI afterwards - the GUI will be snappier at 1080p. This scenario is generally applicable to all ARM devices, nothing that specific to RPi hardware.

You might need to force the Wireless Regulatory Domain for your counrty so the card is using the right radio properties before all frequencies show up correctly. In LE 9.2.3 this will be in the GUI (settings add-on). Until then it requires a conf file setting. e.g.

echo "options cfg80211 ieee80211_regdom=DE” > /storage/.config/modprobe.d/cfg80211.conf

Kodi v19 (LE10) will be entirely Python3, no Python2. It sounds like add-on authors are starting to retool around Py3 which is good.

I'd create a system.d service in /storage/.config/system.d to run the "route add" commands as systemd allows you to add dependencies to accurately sequence when things will occur, e.g. after network-online.target but before kodi.service (assuming the routes are needed for Kodi things).

I must have been asleep when I read the first post. if you want to "install a greek build" you're probably in the wrong forum for futher help. Our views on builds and wizards and piracy in general won't be compatible with your goals.

SSH into the box and run "tail -f /storage/.kodi/temp/kodi.log" and watch the output on-screen stream past. When it stops, Kodi crashed.

Add "ssh" to kernel boot params in extlinux.conf and then you should be able to SSH in and collect some logs, and if you're lucky there are some error messages that indicate what's going on. If not the collective shrug is "no idea" .. we're not box lairvoyants

If you look at one of the early attempts at PR'ing support project: add wireguard package by chewitt · Pull Request #3498 · LibreELEC/LibreELEC.tv · GitHub I was using a homegrown wg-quick script that works (in a basic sense). bash isn't the only challenge with the upstream script, iproute2 is missing capabilitties too.

Having never knowingly seen the cpu-z app I can't say, but as a rule Android only tells you what the manufacturer exposes in the device-tree config and box vendors have a reputation for faking info .. esp. with "MXQ" box which are cloned and sold by many different manufacturers. The one true method is, you open up the box and share post a high-resolution image of the front/back sides of the board so we can see what chips are on it

We suck at guessing so you might need to explain what kind of wifi is in the box?

HW acceleration is still a bit work in progress. It was working .. then kernel side was reworked around a newly finalised API late last year and that needed a bunch of rework in FFmpeg which has taken an age to happen. It is now being very actively looked into, but we didn't have a eureka moment that results in publc-usable code yet. However, on VIM3 you should be able to disable HW decoding and it will decode all 1080p content happily - only 4K will be too much. NB: USB Burning Tool uses a proprietary Amlogic "img" format, so not possible to use that.