Posts by chewitt

You can dump the existing database and then import the dump to the new database before changing advancedsettings.xml to use the new DB location. There are lots of howto guides for dump/import on the internet. Most of them aren't discussing Kodi database migration but it's nothing Kodi specific.

Apr 07 20:34:00 LibreELEC modprobe[241]: libkmod: kmod_config_parse: /etc/modprobe.d/blacklist.conf line 1: ignoring bad line starting with 'rtl88XXau'

so..

echo "blacklist rtl88XXau" > /storage/.config/modeprobe.d/blacklist.conf
reboot

and try again..

Quote from mediatex

Is that the right LE version for my box?

First read this: https://wiki.libreelec.tv/hardware/amlogic

Then create a new SD card and follow "box" instructions (no upgrades). The p212 device tree should work.

I'd suggest to use an LE12 nightly and experiment with different dtb files. The p212 file will probably work best.

2024-04-07 13:05:18.389 T:1107    debug <general>: OnPlayBackStarted: CApplication::OnPlayBackStarted
...
2024-04-07 13:05:29.383 T:1473    debug <general>: CPtsTracker: pattern lost on diff 83389.000000, number of losses 1
...
2024-04-07 13:07:28.544 T:1473    debug <general>: CPtsTracker: detected pattern of length 1: 41708.24, frameduration: 41708.333333

It might be odd timestamps in the file. I see ^ logged which matches the "couple of minutes" theory. The file plays fine here on RPi5, but that's because RPi5 doesn't hardware decode H264 media (so it's the same workaround as disabling DRMPRIME).

popcornmix  HiassofT might be able to explain more. I don't have an RPi4 around in current location.

The "box" image has bootscripts to hook into vendor u-boot and make it run an LE image. Your box has nothing on eMMC (either it has been erased or eMMC has failed) so there is no vendor u-boot to hook into and thus no boot with that image.

The "board" images for VIM1 and LePotato have modern u-boot compiled for those specific boards installed (to the boot media: in this case an SD card) and these use modern u-boot config files (extlinux.conf) not Amlogic vendor boot script garbage. The files used to create/sign modern u-boot are device-specific so it's unintentional and unusual that your box can also boot with them.

You should be able to use the "box" image with the p212 device-tree, read: https://wiki.libreelec.tv/hardware/amlogic

NB: There are no drivers (that work on upstream kernels) that exist for the WiFi chipset in the box.

frakkin64 explanation sounds right. The LePotato dtb has no WiFi SDIO node and the VIM1 forces a Broadcom chipset so if boxes have Realtek/Qualcomm chips things either won't probe or will probe the wrong chip and fail.

Current LE12 nightly images have changes to boot files and even on VIM1/LePotato you'll now see an /amlogic folder that has all the dtb files inside (not just VIM1 or LePotato dtb) so experimenting is a simple as editing the dtb name in extlinux.conf.

RPi5 is stable and reliable (with LE12 images) so this sounds like something specific to twitch.

Read here: https://wiki.libreelec.tv/support/log-files

The image is nothing do with us

It runs on hardware we don't support

There is no source code

Can you upload/share a sample file somewhere?

If you disable hardware decoding, does the file play normally?

Are you running a stock LE release or one with "improvements" or "fixes" included?

Kodi supports updates so as long as the Kodi version keeps moving forwards; e.g. K20 to K21, or K21-beta1 to K21-rc1, then settings are preserved when updating and micro bumps from an older nightly to current nightly are low drama when we're late in the Kodi release cycle (in pre-Alpha things can be different).

Kodi does not support downgrades; although minor roll-backs e.g. moving from a current LE nightly to one from a couple of weeks ago to avoid an issue will normally work without issue. Downgrades where the Kodi major version changes cause issues.

Users with good backup habits or update paranoia can always generate a backup in the LE settings add-on

Oleg's images are largely based on the upstream kernel which supports RK3588 + RK3568. It's the first time I hear of RK3528 and while I don't actively track RK matters that's normally a good sign there's no support for that chipset.

Google shows this patch being advised/required in a couple of places: https://git.launchpad.net/ubuntu/+source…435523d2f374161

So the probable reason it doesn't work is: LE doesn't include that patch, or the udev rules file it's modifying, or the hid2hci binary that would be used if we did.

Simple binaries that aren't compiled/linked against other libraries can often be copied from e.g. Ubuntu and used on LE. So I would try copying hid2hci to /storage/bin/ and the 70-hid2hci.rules file to /storage/.config/udev.rules.d/ and then mod the rules file (with the changes in the patch) so it runs "/storage/bin/hi2hci" (explicit path) not "hid2hci" (which relies on the binary being in $PATH).

Quote from trent

Maybe buy a cheap wifi router and set it to wireless bridge mode

^ this is what I do for test/dev simply because it avoids the effort of configuring a WiFi connection. Not that configuring WiFi is such a major effort, but after a decade of test/dev the novelty wears off. I have a bunch of older Apple Airport Express things which are not so fast these days, but compact and (when I got them) cheap.

echo "rtl88XXau" > /storage/.config/modeprobe.d/blacklist.conf

I did some more Googling and the v3 might be an RTL8822BU device, so blacklist the vendor driver to stop it loading and see what happens after rebooting. Share the journal log again pls.

I think the Q is best asked in the Tvheadend forum: https://tvheadend.org