Posts by chewitt

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.

Quote from madmax2

What is the purpose of putting out a 10.02 image for pi3b+ if the performance is worse than previous 9.2.8?

-HEVC 720 10bit and 1080p 10bit HDR is now no longer watchable...

Why was MMAL removed and replace with DRM PRIME (enabled by default) which is useless on the Pi3B+?

Will DRM PRIME ever get proper HEVC hardware acceleration as good as MMAL and how long we can expect to wait for proper support?

-At this stage DRM PRIME is just terrible and has no benefit for HEVC decoding, and it actually makes HEVC decoding worse.

The purpose of releasing is so that users who need to run Matrix (and in the near-ish future, Nexus) can update their devices. For users with older RPi hardware it's a mixed bag because the upstream switch to a common GBM/V4L2 video pipeline (standardisation) means there is no longer any support for the older OMX/MMAL decoders. They were removed (along with iMX6 and Amcodec) to reduce the code spaghetti that had made Kodi increasingly impossible to maintain (fix something for one and you break something elsewhere): we did table-napkin maths at Kodi DevCon and estimated 38 decoding path combinations are reduced to 6 paths and with more work can reach 4 in the future. When it is used used with appropriate hardware, DRMPRIME is great. For example: For hardware with appropriate kernel drivers Kodi now supports HDR properly with 8/10/12 bit output - HDR support on RPi4 is now awesome (the comparison with LE 9.2 is night/day).

The software optimisation done for HEVC under the older proprietary decoders was extremely clever, but also a huge hack, and requires a substantial 50,000 lines-of-code patch to ffmpeg that would never, ever, be upstreamable. In the mid-term future we will be running ffmpeg with upstream only code and no meaningful patches. That makes distro maintenance a lot easier, not just for LE, and means RPi hardware will start working the same on all distro's and not just the limited few dumb enough to allow 50,000 LOC patches in their codebases.

There is no plan to redo the huge invasive code hack for older RPi hardware because (as before) it would never be upstreamable. After 10-years of hoarding custom patches in their own Linux fork the RPi Foundation has learned the cost of downstream development and the value of upstreaming. LE and Team Kodi have been one of the catalysts for change in their approach. We're proud of that, and we've been thanked for pushing them into making the changes, because standardising and upstreaming is benefitting their business model.

So .. as has been published multiple times; you are welcome to continue using LE9.2 if you depend on HEVC support.

Using OpenVPN will place your unprotected LE device on the public internet. It is not designed for that. So the security engineer in me wants to polietely suggest that users who don't know how to use VPN software (or can't Google and figure out an understanding) .. shouldn't use VPN software. I'm not trying to be an arse; I just don't want to see people getting shafted by scanning bots that *will* find and start brute-forcing an LE box rather quickly.

I can't speak for CE and the vendor kernel, but the upstream Amlogic AIU/AXG driver code supports 24-bit/192KHz audio on S/PDIF.

AV1 is still rather new so there isn't much 'open' hardware supporting it in circulation and the few 'streaming' sources that offer AV1 content also support H264/VP9 so it's "nice to have" not "must have" for now. The RK3588 SoC is promising; but boards for that are only just starting to be released, they aren't particularly cheap (not that anything is these days) and nobody wrote V4L2 drivers for the AV1 codec in the SoC yet (although there are firm plans to write it and we know the Collabora developer who has the task for a commercial project).