Posts by chewitt

therealwolve Your continued posts nit-picking how we adminster the forum are tiresome and taking more time/effort to respond to than dealing with actual spam (which is rare, as we have effective measures in place to prevent it). If you continue to grind the axe on this topic your forum account will be suspended so everyone can focus on helping users with actual problems.

The Generic build-system "Project" was organised into "GBM" and "X11" build-system "Devices" to emultate the build-system project/device organisation we use with ARM SoC images. This keeps the build-system compact, but the current update process only uses Project (not Device) when requesting update tar files; and the JSON data only supports the GBM files. In hindsight "Legacy" should have been done as a separate Project (as was done in the past) .. but it's a bit late now, and in the mid/long term the X11 image is hopefully dropped anyway.

cd /storage/.update
wget https://releases.libreelec.tv/LibreELEC-Generic-legacy.x86_64-11.0.3.img.gz
reboot

SSH into the box and run the above commands ^

Then say out loud "fcuk me, that was so much easier than trying to self-host images and JSON files" .. and go watch a movie or do something fun with your kids/partner/pet.

Did the deletion of a bunch of out of date files break your box? .. no

Does the 11.0.3 update fix anything critical for AMLGX installs? .. no

Can you continue using your box the same as yesterday simply by turning it on? .. yes

"nothing to see here, move along please"

I've always found CEC to be slow and complicated and having six or more CEC-capable devices attached to the same AVR causes all kinds of random crap .. so it's disabled in my AVR and I never (ever) test it, and have zero knowledge (or solutions) for any issues that exist. For me, CEC has a large SEP field errected around it.

The script is written for Linux, because nobody sane hosts internet facing services on Windows boxes.

I'm not sure who created the nighltly build you're runing .. but it's not an official one (as we don't build the ARMv8 project) so you need to find the original creator and nag them.

There is no spoon feeding guide, and I doubt anyone can be goaded into writing one. Last time I looked at the script it was fairly simple to read and figure out.

I've removed all the not-quite-11.0.2 images. No plans to build any 11.0.3 images right now (other than perhaps an RPi4 image).

Yes. See https://github.com/LibreELEC/release-scripts/

"systemctl stop avahi && systemctl disable avahi" ?

Get a Flirc USB receiver and use any IR remote you like: https://flirc.tv/products/flirc-usb-receiver

Nope.

The "use an external grabber" does mean some extra $$, but it's also the method that works the same on any past/present/future device; freeing you to use whatever works for your needs and not worry about it again.

Have a read of this: https://wiki.libreelec.tv/development/git-tutorial

In short, you need to create a diff patch that patches the kernel sources either modifies the x96-max dts file or (better) adds a new dts file for your box. Clone Linux kernel sources from https://github.com/chewitt/linux/commits/amlogic-6.1.y then create a new branch and make and then commit changes. You can then generate the diff patches from the commits (git format-patch ..) and copy them into the LE buildsystem at projects/Amlogic/devices/AMLGX/patches/linux/ then rebuild the image so the patches are applied to kernel sources and included in the built kernel. If you modify the kernel build folder direct; a) respinning the image will not pickup the changes, b) if you force the kernel package to be rebuilt this will remove the build folder and unpack it again from sources overwriting your changes.

The suspend/wake code is contained in the bl301.bin file that forms part of the early boot firmware chain; and even though we are using upstream u-boot, we are (or should be) using the same bl301 code that shipped with the original boxes, as I extracted the FIP sources from the vendor u-boot sources WeTek shared with me. If that's not the case, I don't personally have the skillset to investigate the problem much further (and don't have time or interest for learning new tricks currently either) .. so unfortunately, it is what it is

Seeking in HEVC media has flaws and some hangs are inevitable (as you found, stop and restart playback generally works). I can't explain the source changing issue, but I don't see problems with source changes on any of the boards I test with and my own receiver, and it's not something other users are reporting against AMLGX images.

Someone is rewriting HEVC support, but until I see code to test I can't say whether that's a solution, and there's no timeline.

Quote from therealwolve

Why don't you just let the community do the "hard" task and let moderate the forum? Like it's kind of standard nowadays so that users just flag/report content and it will be invisible until a mod approves/removes it?

That way the mods should have much less work and users might be happier because their legit posts are actually visible and not in limbo for hours or days because only 1(?) mod actually does this job.

Relying on users to flag spam doesn't work because when you present a shitty task to a large audience everyone hopes or assumes someone else will do it, with the result that nobody does it, except for the staff/mod users (who are already doing it, and the people doing initial post approvals and the main responders to around 2/3 of the threads in the forum anyway). So it's not really any more or less work for staff, and it's a highly effective spam block. TL/DR; It works, and despite the occasional complaint (which like busses, come along in threes) it's not going to change.