Posts by chewitt

Some Amlogic devices suffer from installation quirks/niggles (unique device trees etc.) and some have shitty firmware so there is always a slight gamble to be made, but 64-bit devices from reputable vendors have a lot of promise and we are working very closely with the developers Amlogic contracted to rewrite and upstream 64-bit platform support into the mainline Linux kernel. That effort should be more or less complete around Linux 4.13, although graphics fettling and tuning will take longer - but we already have private test builds working on 4.11 and the video architecture changes needed in Kodi v18 are in process too. So the future is a little way off.. but very visible. Amlogic is not at pi levels of community focus but it's move a long way from the hideous codebase it was 1.5 years ago. I have zero expectations of S912 fbdev drivers so the 'libhybris' wrapper will continue as the only option for S912 devices like the one you mentioned. That hack seems to be holding up, but it's still a gamble.

I would expect all serious development on 32-bit Amlogic platforms using ye ancient 3.10 kernel to dry-up once mainline support for S905/905X arrives around Linux 4.13, and there is currently zero support for Exynos chips in current Kodi although DRM/V4L2 we're doing might open the door to that changing before v18 ships. Those factoids might narrow your selection criteria.

The sucky answer is "build on Ubuntu 16.04" .. we know that works.

Just create a release thread in the main support area. If it ends up growing legs and runs with lots of posts and activity we'll move it somewhere more permanent, although I suspect we've caught up on support in the near-ish future as 4.11 released yesterday.

I'd ask for your changes to be in your GitHub repo, and for a URL to the repo in the first post of the thread. Keep the first post up-to-date with the latest build details and comments.

Anything involving apt-get is not going to work on LE/OE or OpenPHT (which is based on LE these days). LE supports docker and ls.io have a pre-built container for Plex that can be installed as a Kodi add-on. I'm not sure if OpenPHT supports the same.

Kodi developers changed/improved the buffering code in Krypton. This improves overall playback but results in longer times before playback starts. It's a known/aware problem; the usual complaint is channel zapping in tvheadend or similar. No changes are expected until Kodi v18.

Amlogic support in Kodi v17 is not fully baked and there are some unfinished bits, and this is one of the quirks that shows up on some media - I see it most when trying to skip back in tvheadend time-shift recordings. It's more a case of "working as expected" than a reportable bug so I won't be asking for logs or investigating further. Fixes for current quirks will/should come with Kodi v18 and further overhauling of Kodi VideoPlayer code, and by that point we are hopefully running on a mainline Linux kernel that solves other quirks in the current (ancient) 3.14 kernel.

Cipher changes in LibreSSL that invalidate old/cached keys or an outdated PuTTY version or invalid permissions on the /storage/.cache folder where the SSH private keys are stored (if insecure sshd will not start) are the normal culprit. If you add "tty" to boot params you should end up with a console on CTRL+ALT+F3 that you can investigate from.

URL removed because the video indirectly promotes pirate crapware.

Live mode appears to be missing support for nvme* device as vpeter indicated. That can be fixed, but the easy solution is to install to the SSD instead of running in Live mode as the install script supports nvme devices already. NB: LE installs to the entire disk not a partition. That's deliberate and will not change so if you're trying to do some kind of multi-partition/boot arrangement you'll need to boot Ubuntu or similar to create the partitions required for LE to run from and do a manual install from there.

Have you tried Googling "pinsentry Kodi" ?? It's not in our or Kodi's default repo but it's not that hard to find.

Linux mint 'worked' because it can install the older AMD drivers needed for the GPU in the box. LE doesn't have those drivers (and will not gain them) hence it boots but there's no graphics. You'll find the performance similar on most general purpose distros, even the lighter ones.

This has now been fixed in code and will be resolved in LE 8.0.2

Current Amlogic builds have limited support for DVB devices compared to Generic/RPi builds due to the ancient 3.10/3.14 kernels in use and we are still experimenting with media_build support. We figured out how to backport and build it, but this then breaks other drivers (e.g. IR things) we consider to be more fundamental and important. If you find something that works, great, but if not an RPi3 as the headend device is a good compromise.

NB: Things will improve for 64-bit devices once we move up to a current kernel as we'll be able to use media_build without hacking, but that's months away and 32-bit hardware will remain on the older kernels (noticing one of your boxes is S805).

Nothing stands out in the log (to me) and I use the same add-on daily and never see the issue described. The BBC are changing their site a lot at the moment which is leading to some iPlayer breakage; the add-on authors need a couple of days to react to changes.

NB: In future please use the native "cat /path/to/log | paste" function. It's easier for you, and us.

If we have to guess which DVB devices are in the box we will have to deploy our crystal ball. When this happens our guesses are usually terse in wording and slow to arrive.

I'm still waiting for a sample of a problem file.

Changes must be applied via a diff patch that works on the original download source; see the "patches" subfolder of a package. Patch files use a simple naming structure and are applied in alphabetical sequence. You can work within the build folders, but only to create the patch. NB: The build system will auto-detect new patch files and on next build run will auto-clean the package build contents in build.LibreELEC-blah erasing any changes that you made there, so ensure you save them all (as diff patches) before rebuilding. If you want a "developer" workflow for changes it's best to have original sources in a git repo and then you only need to change package.mk to update the githash to pick-up your latest changes.