USB boot may require a specific port to be used.
Posts by chewitt
-
-
I can see time jumping around several times in the OS boot log so you might want to delay Kodi startup until the network is up and NTP sync occurs; this prevents issues with invalid certs due to OS time being before the start time of TLS certs.
However that repo has piracy content in addition to Bulgarian subtitles so I don't care about it working. The logs show the issue clearly.
-
LE has good core OS support for SM1 (S905X3) hardware but there are no drivers for the Amlogic WiFi chip thats inside and unresolved issues with 10-bit output and hardware decoding. You can run LE but only with software decode up to 1080p and Ethernet. There's no device-tree for that box but there are several other SM1 devices based on reference designs which will probably work.
-
This would be a feature request for Kodi not LE. You can make Kodi feature requests via the Kodi forum.
-
No, because Kodi does not support this.
-
LE10+ images no longer have optimised software HEVC decoding so performance is expected to be worse (no bug to report). It's not possible to reinvent the same level of optimisation using the newer video pipeline that we are using now. I'll also pass the comment that RPi02W is not supported hardware in LE10+ due to 512MB RAM being generally insufficient for a good Kodi experience now. It will work better on the LE9.2 codebase; although we have deliberately omitted support there because we don't want to encourage people to buy RPi hardware that is not supported in later releases.
-
I'll try that. I'm checking https://test.libreelec.tv/ and it seems there's only builds for RPi2 and RPi4? Mine's a RPi3.
Use the RPi2 image then.
-
Damn! Tried the toothpicked and it booted ,weired, all my other distribs boot directly, but let`s see
q200.dtbLE uses different u-boot bootscript, so unless you (re)load it by forcing recovery boot you're trying to use legacy boot scripts which don't see our boot files. You'll need to do the same (for the reverse reason) if you revert back to older distros.
NB: I'm not aware of any issues with networking or repos. If you want any help with that topic you'll need to share boot logs and Kodi debug logs (not non-debug logs) so we can see what errors are reported.
-
For Sunvell T95V Pro tv box, image and device tree please.
Just experiment with some gxm box dtb files .. e.g. Q200.
-
FYI, this was submitted to the upstream kernel yesterday: https://patchwork.kernel.org/p…[email protected]/ .. so there will be a dtb in future nightlies. I also have the u-boot sources from Beelink so should be able to organise support for reimaging the box (installing to emmc) with upstream u-boot support too at some point.
-
Hello! - Please i want to install image and device tree for Mecool M8S PRO L. .. Thanks for all!
There's no specific device-tree for that box but I would try meson-gxm-mecool-kiii-pro.dtb as it probably uses the same IR remote. As long as it uses Broadcom WiFi the boxes are all much the same.
-
FUSE was historically used in the OS for NTFS and exFAT drivers. From our perspective it is no longer required as recent kernels have native drivers for both. I don't recall it being removed, but it's quite plausible that it's been dropped - and I wouldn't expect it to return. NB: That distro has deliberate "native" support for features which are strongly associated with piracy use-cases. Users might not care but we do.
-
In the absence of a boot log that would show what the system is currently doing we can't say. If both GPUs are active the Intel one will be chosen first because we check Intel IDs first (and may find a match). That can be negated by blacklisting the Intel drivers (if they are built as loadable modules not built-in) or by overriding the udev rule that matches GPUs to skip the Intel section and go straight to nVidia. It's years since I touched x86_64 kit so I forget which is easiest or most applicable to current LE images; but maybe the udev approach.
-
Add-ons in /usr/share/kodi/addons/webinterface.default/js/kodi-webinterface.js are part of the squasfs SYSTEM file that we mount on each boot. If you want to modify the content of that add-on you need to patch the add-on sources and then (re)compile the change into a new LE image. Bedtime reading:
https://wiki.libreelec.tv/development-1/build-basics
-
The challenge with locales is .. there are lots of them and the cummulative size of files needed to support a decent number (remembering that we are a Global distro/project) is too large to sensibly embed into a minimialist distro image. The need for non-default locales is persistent but overall not a large volume of requests so we've parked them in an add-on.
-
How about un-thinking the problem and just installing/using the locale add-on?
-
Profile data is always in a users home folder, which LE simplifies by having a single (root) user, and mapped to the persistent /storage area which is writeable. So each time the system boots the profile data is read, and whatever paths and such are needed for locales are set. There are also helper functions in the OS that know to search the binary addon paths for system.d, profile.d, udev.rules.d content etc.
-
Hello. I have a Beelink GT1 Ultimate (gxm_q200) currently running Alexelec(coreelec fork) on SD.
I assume you're asking for help in here because the CE devs have no interest in supporting the piracy-ridden fork that rips off their efforts that you installed on your box. I'm equally disiniterested for a) the same reasons, b) because it's not even a fork of the modern-kernel codebase that LE uses today.
NB: As a random coincidence I created a device-tree for GT1-Ultimate earlier today for one of the Manjaro ARM devs to use, so support for the box should filter through to LE11 nightlies sometime soon.
