Posts by chewitt

Major version update normally triggers add-on updates (as new repo, with new higher-versioned add-ons available) but on first boot the existing old-version add-ons will start/run and then updates will happen. With LE12 on an RPi4 the LE11 "arm" CPU arch add-ons are no longer binary compatible with the LE12 "aarch64" userspace and don't run, spewing some messages. Once the normal wave of add-on updates are processed you have aarch64 compatible versions of add-ons installed and all is good again.

Raspberry Pi did not pay mesa; they paid a well-known and respected developer shop with tons of mesa experience. Work on the mesa changes needed for RPi5 was done 6-9 months ahead of product launch so that on announcement day (one month before public availability) a refined pull-request could be submitted to add mesa support. Similar things were done with essential Linux kernel and DRM (VPU driver) changes too, and their own firmware blobs were in a "final" and well tested state. The result was: on public availability date -90 it was possible to create a shipping/releasable product on an RPi5 board. Some of the LE staff had alpha boards earlier; but things were already at a point of maturity where creating an initial RPi5 image took me 58 mins from unpacking the board sample to booting a daily-usable LE image on it; and that includes 30 mins image compile time. I'm lucky to have a fast box for compiling on, but that speed and simplicity was really about RPi5 being derivative from RPi4, and RPi devs having all software in a usable state. Raspberry Pi understand that average hardware with amazing software support trumps amazing hardware with average software support.

Rockchip and most other SoC vendors simply don't understand that software-focus, it's not in their hardware-oriented corporate DNA. They still ship average/poor "Hey Mom, it booted!" quality Board Support Package (BSP) kernels with their new products. In the case of RK3588 it was also missing major subsystems like HDMI. The Engineering saying "You can have it fast or cheap, choose which one" applies; and Rockchip and other vendors consistently pick "cheap" and rely on "the community" to rework their BSP code and write missing drivers from scrtatch, then send it upstream to the kernel. They do have staff assisting kernel development, but the lions-share of the upstreaming effort is done by hobbyist developers in their spare time, or professional Linux development shops working pro-bono because they hope to gain in the long-term from acquiring expertise and reputation, and becoming the go-to destination for funded commercial projects. Those folks are amazing, but they understandably prioritise pro-bono work below anything chargeable, so the process still runs slow.

RK3588 shipped two-years ago this week. It is still 6-9 months away from a viable LE image with hardware decoding; although we will probably add support for boards in a "software decode only" state earlier. The same is probably true of RK3568 which does have easier decoder needs.

balbes150 has some LE images for RK3568 available. I can't speak for how things run; there's a language barrier and Oleg hides sources on bitbucket behind a terrible GUI and obscures development with "one month of changes grouped in a single commit" which complicates change tracking to the point where nobody can be bothered to make the effort.

There is also https://github.com/LibreELEC/Libr…ment-2097736658 which shows promise; though it sounds like codecs are still incomplete or missing if things are limited to 1080p (sounds like software decode or legacy VOP use).

Quote from Wolkenstuermer

Do I have to do this everytime I want to start the LE System from SD card or just once?

Just once to initiate the loading of LE bootscripts which inject an extra step into the boot sequence. Once done, it will look for LE boot files each time. If not present (no card inserted) it will fall back to Android. NB: Should you choose to revert back to CE you will need to repeat the process with their SD card .. we are both modifying the same thing, but use different boot files.

And yes, the hold-button, power-on, release button trick is required. I've no idea on the "reboot to recovery" as I've spent no more than 10 mins in Android over the years. It will be harmless to try though.

It should work fine, but since all three devices are network connected it's easier (after basic install, and assuming all three devices are the same, e.g. all RPi4 boards) to stop Kodi on the new devices and then scp the existing config/bits over from the master system to the new ones, then restart Kodi. I would scp the the contents of /storage/.kodi/addons and /storage/.kodi/userdata only.

scp -r /storage/.kodi/addons [email protected]:/storage/.kodi
scp -r /storage/.kodi/userdata [email protected]:/storage/.kodi

It's best to report this to Kodi devs via their forum as it's a Kodi issue and not something specific to LibreELEC.

Quote from martch

Is it a recommended update for a RPi 3b?

If you're on LE9.x currently I'd suggest experimenting with a different SD card first as there are differences (reduced support for HEVC and no 3D). If currently using LE10 or LE11 then just update.

It's complaining that the memory region that you're trying to reserve/allocate is wrong. This might be something to do with 32-bit vs 64-bit kernels (different addressable ranges) or it might simply be that something else is using that range. Or it might simply be a case of different-on-Meson8. Some kernel archaeology is required: go hunting for the same/similar sections in ye olde 3.10 kernel device-tree files to see if you can see what parameters are being used.

Quote from Cubytus

"ghost" media that disappeared in a HDD crash. I replace them whenever I can, but not actively looking for them. I know it's not the "cleanest" way to keep a list, but I haven't found a decent tool that would spit out a text list according to a given criteria. How can I extract said "ghost" media?

Kodi Settings > Media > Clean Library should remove anything that's missing. IIRC there are Kodi add-ons that run this on a schedule or you can do it the old-school way and invoke a clean using the command line "kodi-send" tool from a cron task.

Quote from Cubytus

The "viewed" state. Can this part of the database be restored over a fresh library scan?

Just backup the DB files and guisettings.xml/sources.xml/passwords.xml files (and for bonus credit, the add-on settings files) then stop Kodi and restore them to the clean install before restarting Kodi .. and on restart it will migrate (update) the DB files to latest versions with all content and viewed state intact. The guisettings.xml file handles all the rest of Kodi GUI config and if you backed up the add-on settings you still need to reinstall the add-ons but nothing needs to be reconfigured from scratch.

Learn how to do that ^ and Kodi updates from a clean install are trivial and take 5 minutes.

The v4l2-request calls will fail because it's the wrong API for the silicon, but while ffmpeg falls back to software decoding you're still using the DRMPRIME path so you benefit from zero-copy in the output chain which is more efficient.

To get the vdec driver to at least probe you'll need to transcribe the device-tree bits for canvas and vdec over from the meson-gx dtsi files (from fuzzy memory that's where bits live) and mark them as gxbb compatible. It will either work or not, depending on whether there are register differences. The hardware register and init sequences for this era of device are full of magic values and the vendor device trees c.2012 are borderline unreadable when you compare them to anything current (device-tree evolved somewhat).

You need to initiate recovery boot (toothpick method etc.) else vendor u-boot will not look for LE boot scripts (which are different to CE boot scripts). The storage partition on the SD/USB is empty until first boot.

stevie101 Some facts and guesswork:

a) Amlogic requires the v4l2m2m stateful implementation not v4l2-request which is used with stateless silicon.

b) The current (incomplete, staging) codec drivers were written for GXL but will work on GXBB and GXM too (and with notable issues on G12A and up) but while it is probable the current H264 (working) and perhaps MPEG1/2 (broken) codecs are compatible with Meson8 silicon, there is no platform ifdef plumbing for Meson8 in the "vdec" driver so none of the current codecs will be seen as compatible or available to V4L2.

c) Firmware blobs are involved in stateful decoders so while I do not actually know, I also wouldn't be surpised to discover that some different firmware blobs are required for 32-bit arch or simply "older silicon" compatibility (newer blobs are needed for newer silicon and Amlogic is known-bad at backwards and forwards compat).

1. Yes, the schema will be updated as part of the database migration

2. Yes, create a clean install of LE12 on the RPi4 and stop Kodi and delete /storage/.kodi/userdata, then with the RPi3 powered on and connected to the network, SSH in and "scp -r /storage/.kodi/userdata [email protected]:/storage/.kodi" (change the IP for whatever the RPi4 is using) to recursively copy the essential Kodi config over to the RPi4 using scp, then when done, restart Kodi and the DB migration should start: run "tail -f /storage/.kodi/kodi.log" to see it happen. Adapt the same scp command to transfer any other bits of config that are important.

NB: On the RPi4 you will need to reinstall repos and add-ons. We have intentionally not copied them due to the Python2 to Python3 change in LE10+ and the arm > aarch64 change in LE12. However their settings data was already copied. Everything else should be in the DB on the NAS. If you find something is missing you almost always stop Kodi, scp the data over, restart Kodi.

If you enable "password disable" passwords don't work, so do the reverse and they should work (again).

There is something odd about your LE11 card because here (on macOS sonoma) the /storage partition is not mountable on an LE11 card; same as LE12 and any previous LE version that I can recall (back to OE days). macOS has never supported EXT4 filesystems.

Please provide a Kodi debug log.

I've recently been migrating Tvheadend documentation over to a new Docs/Wiki site https://docs.tvheadend.org and one of the text blocks I've moved talks about how multi-tuner setups on Raspberry Pi hardware can be troublesome. The issues flagged are power; as often you need to run tuners from a powered hub to ensure the current draw is handled instead of being directly connected to the Pi board, and bandwidth as this arrangement results in the tuners being connected to a single USB port. Then for extra credit it mentions that RPi 0/1/2/3/4 boards are sharing USB with Ethernet. RPi5 runs Ethernet from a proper PCI bus which should eliminate the latter issue, but the other issues are still possible.

What happens with one tuner connected directly and other tuners connected via the hub? (experiment with different combinations)

Please post the entire debug log else you eliminate all the useful background technical info on your setup, and all the useful info on the media being played. Just run "pastekodi" and share the URL.

The last official WP2 image with support for the internal tuner is LE 9.0 and there's a community image for LE 9.2. The newer AMLGX image has no support for the tuner cards and S905 is from 2015 so I really wouldn't waste $50 on WP2 as an upgrade. If the WP1 is working for you as a DVB-C receiver I would continue to use it as a network tuner-only device and invest the $50 in a new client box or board. RPi5 is my go-to recommendation but probably needs a few more pennies than $50 saved.