Posts by chewitt

Quote from Champ222

do you know if the database files have changed between version 9 and version 10 of LE?

Yes, Kodi major version change will always increment the DB files.

Borygo77 .. no support for Pirate add-on users.

https://wiki.libreelec.tv/configuration/edid <= Capture the EDID data from the HDMI connection and set this in kernel boot params and then the HTPC device sees the AVR/TV as always connected.

It's rather unlikely that our software killed an RPi board (would be the first time it happens that I can recall) and if there was a general issue or risk with software/hardware we'd have seen it lots due to the volume of RPi users we have. Was the same PSU used with both boards? - that would be a more likely route to damage.

LE/Kodi can do all of the above, and boring is good (doesn't involve drama/excitement and support effort). RPi4 would be strongly preferred over RPi3 these days.

systemctl stop kodi
mv /storage/.kodi /storage/.kodi-old
systemctl start kodi

^ that will give you a clean instance of Kodi to work with. If you have important content (thumbs/libraray/etc.) you can stop/move/start Kodi to restore individual items to the active instance. Pirate add-ons are frequent causes of problems, but that's self-inflicted punishment. In this forum you *will* be judged; by being politely asked to go look for support somewhere else if you have them installed.

I'd like everyone to stop "testing" and try watching some movies instead, or go play outdoors with the kids for a while instead of trying to act like uptime monitors for infrastructure that's being actively changed and fiddled with.

Quote from istoric

Full debug log here: https://paste.kodi.tv/jodirerixo

The log shows LE 7.0.3! .. so please find a spare SD card and try the LE 9.2.8 image.

Yes, if the local Samba server has been turned on (which it should be, by default). Expect tagging with Piccard to be slower though as that requires files to be read and written to the remote share. I'd suggest you map the source in Kodi to one dir on the USB, and place new but not-yet-processed files in a separate location - in Piccard you can have it move files to a new location (the source dir) after tagging. This way the filing structure is effectively managed by Piccard.

btw, doing some testing and I confirm that when you shutdown the box, it restarts itself again after a few seconds. I'll ping kernel maintainers on the topic but I'm not sure it will be resolved (or resolved quickly).

Quote from mgear

Does it mean these boxes will never get the latest Kodi? For example, if I have some sort of x96 (s905x) and could not run anything but your build on it and it was Leia, then it's the end of game with this box? I mean of course it's always possible to install Kodi on native Android, but what an unhappy day it would be...

It means there is no way to boot K19+ on devices running 3.10/3.14 kernels as support for amcodec has been exorcised from Kodi (along with a bunch of other undesirable proprietary decoders). There is some upstream development on S802/S805 allowing them to run newer kernels, although the pace of work is rather slow since there's only one developer (with a busy day-job) and there are numerous drivers needing to be written from scratch after laborious analysis of the orignal vendor code (which is horrible quality) along with ESP and blind guessing. S812 devices have the same status but with some extra issues. Right now the media capabilities aren't there so most active use with modern kernels is centred on gaming distros (Lakka, etc.) which don't need them. Marginally newer S905 hardware has reasonable upstream support (including media things) now and S905X/S912 are rather good (4K/HDR/etc. is working). S905X2 and onwards are better on CE right now.

Quote from JoeAverage

Wouldn't it be better to enhance /etc/os-release with one entry what matches the subdirectory (seems to be the machine model ?) on the download server ?

You can get hints from "dtname" or "dtfile" although the device-tree compatible strings do not 100% correlate to $UBOOT_SYSTEM names for all devices we support. I wouldn't personally invest huge time in update scripts because the mid-term design goal is to facilitate switching between release and any nightly build available on the test server from within the GUI (via the settings add-on).

cd /storage
wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz
emmctool w LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz

If you're feeling brave, some figuring out happened and that image ^ should result in a WP2 box that boots and runs LE with upstream u-boot from internal storage instead of SD card

cd /storage
wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz
emmctool w LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz

If you're feeling brave, that ^ should result in a WP2 box that boots from internal storage instead of SD card

This mornings achievement unlocked is .. booting a WeTek Play2 box from upstream u-boot on eMMC

u-boot log https://pastebin.com/raw/pVSHMueQ and dmesg https://pastebin.com/raw/n5E3Rq96

Some more testing is needed, but hopefully this also works with other S905 board/box devices.

You can store files on the PC (or low-power NAS device in the network, or the USB drive attached to the PC) then share the files to the RPi and create a network "source" for the shared files instead of having them directly connected to the RPi via USB. You can now rearrange them into whatever filing structure you like on the NAS/USB drive, or (recommended) use MusicBrain`z Piccard to scrape/tag and automagically store the files for you. You'll still need to 'scrape' the files into the Library on the Kodi side but once the tags are redone with MB that process is very accurate and the Web GUI should have a "refresh library" button. I'm not aware of Web GUIs that make playlist creation easier - Kodi is rather designed to do that kind of thing from the TV interface, but avoiding the need to fixup meta/scraping (because it's done properly by Picard) is normally a good win for music management.

FYI, LE builds official add-ons for 3x "PROJECT=" buildsystem targets: x86_64, ARMv7, and ARMv8 - and that covers all hardware we support.

All the possible options are defined in the build-system, see https://github.com/LibreELEC/Libr…master/projects and https://github.com/LibreELEC/Libr…ts/uboot_helper - the only things that become variable are the build date and githash, which you already understand.