Posts by chewitt

I've pushed an update which contains some changes to SD/eMMC speeds. Any difference on UH-9 hardware?

It's an FTP client so it supports FTP commands. Reboot isn't an FTP command. You can look at the TTYD add-on which provides an SSH client via browser, or using the Kodi web interface, but if the system isn't accessible via SSH it probably locked up so alternate methods probably don't work either. Focus on solving the root issue .. why does the board lock up?

The GeForce 8600GT should be supported by the 340.xx driver in the LE12 Generic-Legacy image, but drivers are always a bit of a lottery on really old and low-mid range hardware as functional testing always focusses on high-end cards with more features.

I don't think you need to force video= in cmdline.txt, but I think enabling composite output in config.txt results in the same situation where the output is active and because the kernel cannot detect whether something is connected or not there is no fallback. At least, I assume that's the case, as these days I have nothing that accepts composite input to experiment with.

Kodi boots whatever config exists in /storage/.kodi and if there is none (because you stopped Kodi and then renamed the folder to something else) it will autogenerate a new one (until you stop Kodi and rename or delete it again).

No opinion on the hardware, but if you configure anything with a pirate IPTV feed that contains a few thousand channels and a full IMDB's worth of 'on-demand' content; it will run like crap, but that's a self inflicted problem, and the sole fix is .. remove the pirate feed. I'm making a few assumptions there, but if that's what you're doing please re-read forum rules before asking for further help.

If you enable composite output or add video=Composite-1:720x576@50ie to cmdline.txt output is forced to that always regardless of whether HDMI has been connected. And because there is no handshaking with the (analogue) composite output, there is no way for the kernel to know nothing is connected and fall back to another display method. There is currently no VNC support for the GBM/V4L2 output we use.

The least-worst idea I can come up with is creating a script add-on that allows you to select/choose between composite or HDMI output in the (add-on) settings GUI and then reboot to initiate the change. That doesn't exist though, and I'm not volunteering

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

^ Those commands will give you a fresh/clean Kodi install to experiment with. To revert, stop Kodi again and rename the old folder back to /storage/.kodi again and things will run as before. There is generally no need to do a full reinstall.

You need to power the box on with the reset button already pressed, then a couple of seconds later you release the button. In the default vendor bootloader this will force searching for and reading s905_autoscript on the SD card, which modifies the boot flow to look for LE boot files on the SD card (with no renaming). It is not uncommon for some experimenting with button press duration to be needed.

I suspect you are either pressing recovery after boot or holding the recovery button down for too long, which results in Android recovery boot, which requires Android recovery .img files. These use the same .img file extension but are something completely different to an LE .img file. Renaming LE boot files to Android boot file names will trick Android recovery into loading a file it doesn't understand, but (as you can see) that doesn't achieve anything.

It would be unusual but not impossible for the box to have a modified vendor bootloader that does not look for s905_autoscript and thus cannot be tricked into running LE the normal way. There usually is a way, but the process requires a serial console on the box to interupt/access the early boot flow and run manual commands. That skillset and process is generally beyond most users; and those with the aptitude for the task generally get on with it rather than asking for help with it.

It's best to take the discussion to the linux-wireless kernel mailing list.

The last LE release that will support a GeForce 6100 GPU (released in 2004) is LE 7.0.3 from 2016 when the project was new. This is still available in the project archive, but it won't be much use for anything except local file playback today, as anything that talks to the internet will have issues with expired SSL/TLS certificate chains and outdated Kodi add-ons.

So the error message is 100% correct .. GPU is not supported. On hardware that old it's not worth swappiing the GPU for something newer unless you have cards kicking around. If you don't, better to save pennies towards something like a Raspberry Pi board or a small form-factor Intel box.

You can add a custom firewall profile to suit your needs, and since the profile file(s) are stored under /storage/.config/iptables they will be included in any backups you take using the LE settings add-on.

NB: I don't see any issues with the WireGuard sample template running on my own setup.

Parallel build failures are either a genuine issue with multi-CPU building on a particular package, or sometimes the result of missing dependencies. In the latter case, re-running the build command may result in a new package build-order, and if other packages are now built before the failed package is cleaned/reattempted, it can build correctly. It's not guaranteed, but free to try..

Look for \\LibreELEC\Logfiles on the network. When you click into the folder a zip file with logs is generated. Share that.

Or read this: https://wiki.libreelec.tv/support/log-files

There's no point in adding Kodi debug info until Kodi runs, so just do "dmesg | paste" over SSH and share the URL generated.

There are multiple issues being flagged in that thread, and some of them are likely due to silicon bugs in Amlogic hardware. So hard to comment on anything, and you share no logs, so ..

Correct, although I'd rephrase it as a general problem with commercial VPN services. It's nothing specific to WireGuard, and not all WireGuard configurations use class A addressing, although that's probably true for commercial services.

Quote from ihipop

any plan to support this?

I'm happy to backport merged patches to our current kernel(s). I'm not interested in adding unmerged stale patches that nobody is working to upstream. I suggest you build an image with the RFC changes, and if they work (or don't) comment on the mailing list thread to revive it and perhaps trigger some activity with the developers.

Those kind of products swap internal chipsets between batches based on what's available and cheap(est) to use. The internals are far from being guaranteed.