Posts by chewitt

read: NOTICE: sx05.eu domain for kszaq builds no longer in use

The Amlogic change that happens in v19 is removal of the proprietary 'amcodec' interface in Kodi. Devices which are stuck on 3.10/3.14 kernels will not be able to run Kodi after this time. Devices which can run a mainline kernel will be able to use the next-generation video decoding and rendering pipeline that supersedes amcodec. Currently S905 devices and newer (excluding S912) can be supported on a mainline kernel. Anything older (and S912) is missing important kernel or driver code and is not supportable.

Kodi is written around ffmpeg and you will not be able to "swap" ffmpeg for gstreamer. Qt now has V4L2 support though, which should allow you to write a Qt app that runs with the next-generation V4L2/mem2mem video pipeline. V4L2 support was added to Qt by a Plex employee who is also an LE team member .. because Plex uses LE as the OS base for their "Plex Embedded" distro.

On Amlogic devices running a mainline kernel there is only /dev/fb0

We never allow/disallow something on the grounds of legality because the law of a specific country have little meaning to an internet based project with a global audience. Decisions are based on project policy which is formed from general morals.

Nope. There is no audio input/mic support in LE (or Kodi) to capture voice and send it somewhere for processing. You need to use an external device like a Google Home or Amazon Echo .. which is what the other poster is doing.

It's not technically impossible. The first challenge will be finding someone with the alsa routing knowledge to do it. The second challenge will be persuading that person this is something worth their time and effort. Most alsa related things fail at the first challenge.

Your next movie should be "Apollo 13" just so you can watch the bit where Ken Mattingly has to figure out the LM power-up sequence in the simulator

Windows allows "shortcuts" to files and folders on remote shares and accessing the local shortcut triggers access to the remote target object. Linux only allows symlinks to objects in a local filesystem so it's your responsibility to ensure the remote share has been locally mounted before Kodi starts and attempts to access the always-local target for the symlink.

Doing this at boot time is not impossible but requires more changes than creating a symlink. It would be easier to create a shell script that can be run via at a "safe" time (e.g. 4am) via cron that mounts the remote drive, compares remote file(s) to local file(s) and if there's a difference you stop Kodi, copy the new file and restart Kodi. There single boot-time script hook in LE (autostart.sh) runs at the very start of boot before the network is up so working with remote files requires task-scheduling trickery. There's also a python startup script function within Kodi itself which could do the same thing .. but you end up with an annoying startup process where sometimes (always when a wife wants to watch something) Kodi starts and then stops and restarts "with no apparent explanation" etc.

The historic reason for rejecting all attempts to add software RAID and drive encryption to LE is that there are many different schemes and the tiny minority of people who want this are quite religious about their personal choice being the sole divine approach to the problem with all others inferior; so if we allow one crypto or RAID scheme we'll end up being asked for more and we end up having to support all schemes which would be complex for the team to maintain and support as each scheme requires detailed functional knowledge. To avoid that we've simply said 'no' and left things in the hands of community creators to spin their own images and share it if they want. It's not my personal decision, but we had these requests since OE days and no "popular" community image ever emerged which I see as proof that this remains a super-niche topic. As such I don't see a strong reason to change our "less is more" approach. It's kept things sensible for a long time.

NB: You will need to use a custom Kodi systemd service to add a dependency on the network mount being available, or you will have issues when Kodi starts and the NAS drives are asleep and need to be spun up for the mount to complete. It can take 20-30 seconds on some NAS units. For sake of avoiding copying as.xml to the local system it's probably not worth the effort.

8.2.4 had a boot problem and was superseded with 8.2.5 which had an overlay issue caused by the final firmware update which I didn't have time to test before the release was posted. As there is basically no gain from 8.2.3 (all the updates are for other hardware) and I am failing to work up enthusiasm to look at 8.2 things I simply removed the update files to stop them from being further used and left things on 8.2.3 which works fine. If your boxes are fine on 8.2.5 leave them as-is. If not roll back to 8.2.3.

btw, I'm told that master branch needs some slice overlay fixes, but I don't know when I'll get around to that, so initial alpha builds (when they finally start) might not be usable.

The act of asking for public help usually allows people to instantly spot the obvious mistake made or it provides a sudden burst of inspiration to solve something

Thanks for sharing the solution.

GitHub has the advantage of allowing others to compare your fork against our main branch (or others) but any public repo is fine and we're not out to dictate anyone's workflow.

sertem только английски язык пожалуйста

Kodi needed to reduce the size of their install binary due to Android store limits so between v15 and v16 they shed bloat by moving lots of tertiary functions into installable addon modules; LCD support is one of them. This means in addition to installing LCD support to the OS (via our addon) you also need to install LCD support to Kodi (via their addon). I'll admit it's not the most obvious thing..

You can only set a single map in dts but look at the multimap config that's done in the v4l-utils package.mk

Android has native voice search API's that allow third-party apps like Kodi to hook into the underlying OS support. There's no equivalent for Linux so voice search will not work in LibreELEC (or any other distro).

Lakka devs already have a bootable XU3 image that should be more or less copy/pasteable into our buildsystem to provide core board support. However Retroplayer != Kodi. If the device has DRM (direct rendering manager) support in the kernel (ideally mainline, worse some odroid specific kernel) it should be fairly simple to get the Kodi (Leia) GUI running as the DRM framework in Kodi is now quite mature and has been tested on a wide range of devices. However GUI != awesome performance and hardware decode will require an Exynos V4L2 driver. If that also exists things become theoretically possible but you'll hit some challenges with V4L2 support being on the bleeding edge of current kernel and Kodi development and some of the 'standards' are still in development and a little fluid right now. The main API that things need to coagulate around is targeted for the 4.19 kernel which is late summer, although things are now close enough to end spec that developers have something to pursue that won't need major rework when things are finalised.

While that's generally positive, the normal challenge with older boards (even great ones) is that by the time all the standards settle down a new one appears (with different chips) and then the number of technically capable people interested on adding support for the old model drops off because they all have new shiny playthings to poke.

LE has installed syslinux bootloader and created two ext4 partitions in a GPT scheme; first is 512MB and the second fills the remaining available space on the drive. The good news is that LE is small and so regardless of where the new partition boundaries have been drawn on the drive we've only overwritten ~235MB of the first (boot) partition space and no more than 20MB on the second (storage) space if it's just a clean LE/Kodi install. The overwritten data is probably only Windows OS files so someone who knows how to perform data recovery should be able to find and retrieve a large amount.

** If you don't fully know what you're doing and the data is valuable, stop immediately and seek professional help **