Posts by chewitt

There's no special/secret repo that we're sandbagging support for that chip in .. support doesn't exist and you need to adapt Linux kernel drivers for H6 and H616 to the H313 hardware and/or author new drivers for anything missing. There is no guide for how things are done, only prior-art from the Allwinner BSP codebase as an example: mostly an example of how to write low-quality code that needs to be rewritten for upstream frameworks, standards, and acceptance.

We'll be happy to test anything you come up with.

Use path substition: https://kodi.wiki/view/Path_substitution

tequomo there are no geolocation restrictions on the addons server. The curl request also shows "failure to connect" which is different from a "connect and server rejected" message you'd see if we were blocking. The issue appears to be at your end.

I'll have to have a look in older branches then.

Reducing the number of drivers being inluded reduces image size and build time, that's no problem. And yes, you'll need to enable the kernel driver in projects/Generic/linux/linux.x86_64.conf - the PR that I linked only adds the userspace Xorg bits.

If a file is marked hidden in the remote filesystem, it's up to the client (app/OS, etc.) browsing the remote filesystem (over CIFS/SMB) to show the hidden files. It's not a server side configuration.

On most Amlogic devices you hold the recovery button, apply power, release after 2-3 seconds, then you see the LE boot splash once KERNEL has been booted. Some devices need 1 second, some 6-7 seconds. I've no idea what you box needs

Box vendors can add a custom boot splash to u-boot (although most do not because it requires effort) and to customise the Android boot splash (most do, because it's simple). I've no idea which one you see

If you box does anything different or needs some different process .. it's impossible to triage what's required without connecting a serial UART device to the board so we can see what happens or fails in the early boot process. That requires a) having a USB serial UART tool, and b) opening the box up to install it, which often requires wires or pins to be soldered to the board. Otherwise we are blind, and blind guesswork is a recipe for frustration not success.

The 'Android' and 'LOST.DIR' folders were created by Android during recovery boot, it's harmless.

Install the add-on and then exit/reconnect over SSH and the stress-ng binary should be in the default $PATH.

Or run openssl speed -multi 4 .. that usually does the job.

Johpin I'm not sure this is complete, but it might be helpful: https://github.com/LibreELEC/LibreELEC.tv/pull/5917

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.