Posts by chewitt

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.

Quote from hybrisred

Maybe the people at Libreelec can somehow make it backwards compatible?  

Maybe the people producing Argon cases can get their sh!t together and fix their product themselves? .. we (staff) are getting a bit fed up with the number of Argon users showing up here experiencing issues due to lack of software support and fiddly/iffy connectors/cables in ther case causing a range of connectivity problems.

It's best to ask for help in the Armbian forums where they have some experience with that driver. LE no longer uses the 4.4 kernel and that driver does not work on anything newer than ~4.10 due to crypto APi changes in the kernel.

ErikSwan https://github.com/raspberrypi/linux/ <= everything is there. There will be differences between upstream mainline kernel and the downstream Pi kernel, but there's a pleasing-to-see continual upstreaming effort so the differences are not so big. Note that you also need to combine this with Pi firmware and the latest ffmpeg version; not specifically for HDR (which is more of a DRM thing) but to ensure you have the latest playback fixes. FFMpeg changes are still being hoarded downstream; the focus is still on features/fixes before that effort will start in earnest.

If you really want to watch iperf(1) install docker and pull a container with the right version inside. I'll leave you to ponder on whether the need for docker on the host will consume CPU that could otherwise be directed towards maintaining Ethernet performance; e.g. whether or not you are the cause of observer effect

I'd also comment that you can test by playing a movie. If the movie plays fine your HTPC + NAS + Network combo is "fast enough" to watch movies and you don't need to obsess about whether the NAS is achieving best-in-class or mediocre performance. Watching movies is more fun than watching iperf (any version).

You can edit the docker .service file (somewhere in the add-on dirs) to add the after dependency; don't forget daemon-reload afterwards to update systemd.

I'm also fairly sure you can just dd the LE image to eMMC, I don't think RK doesn't anything too fancy with boot unlike other SoC types.

I'm reaching the point where I read "Argon case" and some combination of audio/video problem and I skip ahead to the next thread.

Get a flirc USB device and use any remote you like. You won't regret it.