Posts by chewitt

Two things come to mind. First, LE has a local firewall that can be enabled. Second, the ports aren't mapped in the container configuration.

Google limits the number of searches per API key so the default key in the add-on is exhausted quickly. The workaround for this is creating your own 'app' as a Google developer and then configuring/using your own API key (with your own limits). This is probably what the YouTube video is instructing you on.

The buffering issues are something separate: Google has started throttling unofficial clients. Workarounds for this are still being figured out.

cp /etc/connman/main.conf /storage/.config/connman_main.conf
sed -i 's/PreferredTechnologies = ethernet,wifi,cellular/PreferredTechnologies = ethernet/g' /storage/.config/connman_main.conf
reboot

^ Removing wifi from PreferredTechnologies should ensure eth0 always has the default route (maybe .. not tested). You can then create a systemd service file to set defaults routes after the network is up and before Kodi starts.

I don;t know what IP is used for NPU in RK chips but in general NPU drivers are often a challenge to upstream due to NDAs and restrictions on the SDKs from the IP owners.

Just disable update checking in the browser.

It makes no functional difference whether you update from .tar or .img.gz files, but .tar is a little faster. I did make a mistake in the commands though, I did not recreate /storage/.update though I hope you spotted that as the next command was to cd into that dir before downloading the .tar tile. Please check the udpate file is in /storage/.update (note the . it is important) before rebooting to update.

The Kodi Plex add-on is a client with a sole purpose of playing media stored in a Plex server. If you want the media to be visible in the Plex client you need to add it to the media library in the Plex server. If you run a Plex server on the same HTPC host as Kodi (and the Plex client in Kodi) you can map media from local drives. If you run the Plex server somewhere else; you'll need to remotely mount the drives so that the remote Plex server host can see the media on them to add into the Plex server library. Kodi doesn't follow a rigid client/server model in the same sense; the GUI just provides access to media wherever you store it, and in your install that media is local which is easy.

It is not possible to change the behaviour of the Plex add-on without writing code to change the behaviour. As the current add-on is created by Plex staff the behaviour is intentional and I doubt changes to access local media would be welcome.

Linux 4.19 is less-worse than 4.4 but the underlying issue is the same; userspace apps like Kodi and FFMpeg (and g-streamer, not that LE uses it) are evolved around V4L2 kernel APIs and code that simply does not support the vendor kernels. The good thing is - Rockchip has numerous corporate backers funding upstreaming development for chipsets like RK3568 so support is being actively worked on and is starting to land in mailing lists .. and as long as that work follows standards (which it is/does/will-continue-to-do) creating an LE image in the future should be fairly simple.

The precise ordering that's possible with systemd *is* the leanest way. Anything else requires guessing (the timing) and hoping (that you guessed correctly). Note that startup scripts will often need "/path/to/pactl" not "pactl" in them.

Perhaps just create a systemd service to run that command after pulse is running and before Kodi starts; systemd will allow that.

2021-10-12 17:32:01.107 T:3908014960   ERROR: CCurlFile::FillBuffer - Failed: SSL peer certificate or SSH remote key was not OK(60)

It's not the NTP/time issue that invalidates the cert (which produces different error messages). It's also not clear what the issue is, but I'd hazard a guess that something fundamental with the TLS cert is bad, e.g. ciphers supported or perhaps broken chain of authority (signed by someone that the embedded certs in your 9.0.2 image cannot trust).

If you attempt to download https://mirrors.kodi.tv/addons/leia/sc…ktail-1.1.0.zip direct from the console you might get more info?

NB: There are some community releases for S905 devices that are newer than 9.0.2 which might be worth investigating on a spare SD card. Sadly the LE10 codebase is not ready for prime-time use (board support is good, media capabilities are not).

The <incomplete> log shows the SoC vendor is Rockchip so I moved the thread, but SoC model is <unknown> and kernel version is <unkown> which means our ability to guess the <unknown> problem is <unknown>. The lack of technical info from you is rather annoying but also rather irrelevant, because your <unknown> hardware probably needs a Rockchip Linux 4.4 vendor kernel? and our codebase is not compatible with Rockchip vendor kernels. It was in the past, but our display and video pipeline is now dependent on modern (upstream/mainline) Linux kernel APIs that legacy kernels do not support. You might be able to frankenstein an LE image to boot and even start Kodi, but there will be no video decoding in hardware which is essential for playback on an ARM SoC device. To get a more useful answer you will need to provide more useful info.

It is [still] being actively worked upon. No further update at this time.

rm -rf /storage/.update/*
mkdir -p /storage/.update
cd /storage/.update
wget https://releases.libreelec.tv/LibreELEC-RPi2.arm-9.2.8.tar
reboot

^ run that from the SSH console. I'm not sure what the issue is, but if it succeeds - that's good. If it fails you should see more output from wget on why it's failing. We do use dynamic redirection to geo mirrors which occasionally (not often, but it can happen) causes weird issues.

Quote from kongxin

Can you give me some hints?

Hardware? .. what LE image? .. what exactly did you change, and why are you building different versions of the kernel. Our crystal ball is not working this week. Add details please.

Kodi Flirc case: https://flirc.tv/more/raspberry-pi-case-ke-gen2 .. passive cooling and looks amazing.

For iMX6 devices LE is (these days) a dumb consumer of whatever state upstream code/support is in, which is probably not brilliant. I have some minor fixes to push into master but these are for hardware support on the newer iteration of the Cubox-i (v1.5) which has different Ethernet and WiFi chips compared to the earlier variant that most LE users have. It's essentially unmaintained, but once some of the work being done on stateful v4l2m2m decoding for Raspberry Pi goes upstream (and down again) that may improve things. The LE 8.2.5 release is probably the better option on these boards .. although the Kodi version is getting old now.