Posts by chewitt

Ideally this is fixed by setting the TV to "just scan" or it's equivalent. Plan B, use calibration in Kodi. Zoom is wrong.

[Linux] Generic drm/kms implementation by lrusak · Pull Request #11955 · xbmc/xbmc · GitHub

this is also supporting current efforts with the Rockchip based TinkerBoard and Amlogic aarch64 devices on a 4.11 kernel, and sometime in the next week or so an Exynos based DragonBoard should end up in the hands of the same developer. There are no plans for LE to "support" DragonBoards but it has the best (or most-complete) V4L2 stack of any ARM device so it has development uses as we figure out fun stuff like atomic modesetting. Things are moving in the right direction and it's not a unicorn, but there's a HUGE amount of unwritten code between where we are today and the next release of Kodi using Wayland etc.

So best support is and probably always will be Raspberry Pi, but after that there's no clear winner. Right now I'd give Amlogic a minor edge but that's only due to knowing more about the fugly state of their current kernels and the efforts Baylibre are doing to correct them. Rockchip has more code in the mainline kernel, but we know less about them.

NB: S802 is 32-bit and none of the current mainline effort targets Amlogic 32-bit devices. There is a fair amount of IP common with aarch64 platforms but there are differences and nobody is being actively paid to code for them.

chmod 700 /storage/.cache/ssh
chmod 600 /storage/.cache/ssh/*
chmod 644 /storage/.cache/ssh/*.pub

I believe that should restore things back to defaults

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.