Posts by chewitt

Addons are not updated as part of the OS image so Kodi will need to start and then fetch updated addons. Until this has happened things will be a little non-functional. This is how Kodi works - it's nothing specific to LibreELEC. If after a while things have no self-updated there is either some kind of networking issue preventing access to our repo, or maybe something bad in the previous config and you'll need to provide a Kodi debug log for anyone to investigate further.

People give up their spare time to write code. People give up their spare time to create wiki pages. Notably fewer people write documentation than provide code .. such is the curse of most FOSS projects. Feel free to request a wiki account and contribute something back.

We use in-kernel decoding instead of LIRC so you'll need to spend a few minutes adapting configs. The wiki is the reference for how to do it, and it's not that hard (but it's not the same as configuring LIRC on Ubuntu). At the end of the day YOU have chosen to change distro so YOU should expect to spend a little time setting things up again. Please remember that anyone responding to your posts in this forum is giving up their personal free time to offer help. Whinging about everything is not going to inspire them to offer assistance.

Feel free to go and use something else then. One less user moaning about something benefits the project. Whatever works for you works for us.

Follow the systemd mount example in /storage/.config/system.d/ to create a local filesystem mount for the remote NFS share, and either mount the share permanently or use cron to start/stop the mount service when needed, and use cron to run a backup script or whatever rsync command you want for backup (rsync will be quicker than a tar based process).

I'll see if someone on staff fancies a challenge - but it's probably not a high priority. From a quick look the build process pulls in some other packages which is something we don't like in our build system, but it's not an insurmountable problem.

I've taken a mental note to design more white text into the next version (not that I recall there being any in the current)

Kodi v19 is the point we switch from Python2 to Python3.

There's a video for this on our under-used YouTube channel

Amlogic/update.sh: fix issues with binary compatability using UUIDs by MilhouseVH · Pull Request #3071 · LibreELEC/LibreELEC.tv · GitHub should also fix this via other means

It's possible to use "autoscript" files to provide uboot with instructions on what to boot (from) but those files do not exist in current 3.14 kernel images and they are compiled scripts (not just plain text files) so there's a little bit of uncharted work involved. If you don't provide instructions uboot will boot from external media if present.

If the slot is "loose" the easier cure is probably to open the case and ensure the connections to the board are soldered properly and the connector tabs that locate the connector housing in the PCB are either tensioned correctly. Or maybe use a hot glue gun to get things under control.

The real credentials are masked with USERNAME:PASSWORD for security reasons as people post logs to pastebin.com and similar.

Spaces in usernames are always a bad idea.

Rockchip is currently using an older 4.4 kernel codebase and things are in a "basic functional" state; it works and we've learned lots about RK support but it's not perfect and we don't plan on developing it much further. In the near future we will rebase our Rockchip support against the mainline Linux kernel - probably after 4.20/5.0 is released. This will be initially less functional than the 4.4 codebase, but once we start finding and fixing things on mainline we can upstream the fixes directly to the kernel and we don't end up carrying a huge patchset that's at a different state to other hardware platforms. Rockchip video decoding also needs to make the evolutionary leap from using an ffmpeg hwaccel to a proper stateless V4L2 decoder so it's using the same Kodi code-paths as everything else - and that's quite a bit of work. So Rockchip images will not move to Beta for LE 9.0, but the goal is to have everything sorted for LE 10.0 (Kodi v19) latest, or an interim release if possible.

TL/DR; RockPro64 is a nice board but you should not expect the same level of maturity as the Raspberry Pi for a while.

There's nothing wrong with SMB in current images. What is the SMB server?

Intel HDR support in the mainline kernel is still WIP but we're nearing the point where various independent threads of development come together. And once Intel completes HDR support we'll be able to align support for other SoC/GPU types with the same work.

If you can boot another distro from CD do a manual install. Create two EXT4 partitions in a GPT scheme; 1GB labelled BOOT and remaining space labelled STORAGE. Install a bootloader; we use syslinux but GRUB works fine too. Copy the contents of our installer USB to the first partition (BOOT) and crib the bootloader config from syslinux.conf (or extlinux.conf) using BOOT=LABEL=BOOT and DISK=LABEL=STORAGE and then reboot the laptop. If you got the bootloader config correct it will boot.

You can probably use WeTek Play addons since they're based on the same 3.10 kernel codebase.

nadhim You post is (was) completely irrelevant to this thread. It has been deleted.