Posts by chewitt

Quote from spschneer

Could you explain how to do that? I've only used the supplied SD creator to "install" to the MicroSD that I then use in the Cubox. I don't know how to "install" from the USB (which was also created by the SD creator?) to the "storage" (e.g. to the internal eMMC?)

The Generic image includes an installer; we assume that users boot from a USB stick and install LE to a HDD or SSD inside the box, although if you interrupt boot you can also skip the installer and run direct from the USB stick (one-time or persistently). On the ARM side of things we assume users are going to boot and run permanently from an SD card (or USB); either hooking vendor u-boot (on emmc) or using upstream u-boot that we created to boot into LE. ARM images don't support the installer .. hence you've never seen it with the Cubox.

Creating a non-static Qt6 version of the tool is simple, but this won't run on 95% of Linux desktops without lots of Qt dependencies being pre-installed and we've elected to not inflict that on our users.

Creating a static Qt6 version of the tool allows it to run basically everywhere but requires a new Qt6 static build recipe and nobody managed to guess at the right combination of juju to make that happen yet. It's one of those Linux "dark arts" challenges; sounds simple but reality is different.

Plan B (or C?) .. download the .img.gz file you need and use "dd" which is native in every OS and most Linux folks know how to use it.

Failure to set Gbit speeds is normally caused by bad cables, a problem switch/hub port, or (occasionally but not often) hardware issues. It is possible to force Gbit operations and full-duplex mode etc. using "ethtool" but if auto-detection fails this is unlikely to solve the problem.

Please share "pastekodi" URL so we can look for issues in the boot log and see what NIC is actually being used.

If you want to continue using LIRC we still support it and you can continue doing the same things. The only change will be dropping "sudo" from any commands being exectuted since in LE everything runs as root making sudo not necessary. Using LIRC also negates the need for Ubuntu, and all the dual-boot and boot menu things.

However, there is no HOWTO guide for your exact setup, nobody is going to volunteer to write one specially for you, and forum staff generally expect a modicum of initiative to be shown. So have a go, and if you get stuck, ask Q's.

https://chewitt.libreelec.tv/testing/LibreE…95.1-box.img.gz <= set "meson-gxm-t95z-plus.dtb" in uEnv.ini

please share "pastekodi" log URL afterwards, thanks.

The LE installer expects to have exclusive use of whatever disk /dev/device you install LE to so it does not support dual boot installs (and we have never offered to support dual-boot setups, it's too much hassle). However if you understand how to fiddle with partitions and create space for another OS and configure things (maybe, or maybe-not?) then it's completely possible. You can mod the syslinux config (or install grub if you or Ubuntu prefers it) and configure that to create a boot menu offering LE and Ubuntu. For a remote to work with that it probably needs to be the kind that acts like a wireless keyboard since there is no 'OS' at boot time to do fancy remote support. If the remote emulates USB keyboard arrow key navigation and USB is active (should be at BIOS level) it should work. There are probably threads in these forums on all those topics if you go (re)search for them. Again, we don't support dual-boot so there's an element of self-initiative required.

https://wiki.libreelec.tv/configuration/…es#lirc-support <= We dropped the lirc on/off from the settings add-on some time ago (wiki needs to be update) but AFAIK everything else documented there should still apply and lirc can be used if you really need it. Without knowing what other special things you are doing in Ubuntu it's hard to say whether it can be easily replicated in LE without old-school lirc, but in 99% of cases there's usually and easier way. Give detailed descriptions and share code/scripts involved (often more useful and a non-technical users bad description) if you want better guidance.

NB: HDR support requires an HDR capable Intel or AMD GPU (not nVidia) and the LE11b1 Generic image or newer. This uses GBM/V4L2 graphics which means no VNC. If you want to do things remotely you can SSH in use "kodi-remote" to do basic keyboard navigation around the GUI from an SSH client. If you really want VNC then you need to use the Generic-Legacy image, but that uses X11 and thus means no HDR. You cannot have both.

Interesting. I discovered that dtech (staff contributor) has the same box (or at least, something that claims to be - there are lots of clones) so I'll make a device-tree file for you both to test. I'll map the x96max remote to see if that works too.

btw, Ethernet is not working on the box. The same issue has been seen on several GXM devices and I'm not sure quite what the issue is yet.

mkdir -p /storage/.config/rc_keymaps
cp /usr/lib/udev/rc_keymaps/x96max.toml /storage/.config/rc_keymaps/custom_remote
sed -i 's/x96max/custom_remote/g' /storage/.config/rc_keymaps/custom_remote
echo "*  *  custom_remote" > /storage/.config/rc_maps.cfg
reboot

This ^ should define a new custom_remote config that's the same as the x96max remote.

echo "*  *  x96max" > /storage/.config/rc_maps.cfg
reboot

This ^ might be an even easier version (see if it works first). It's been a while since I played around with the keymaps.

If neither of those work, the keycodes need to be persuaded into outputting something with `"ir-keytable" .. I'm not sure why that wouldn't be showing something.

Quote from smp

The image was built with -march=tigerlake gcc flag. It would probably be unbootable on non-tigerlake CPUs.

LE spent a lot of time doing performance testing on chipset specific flags during OE days when our Generic userbase was larger and hardware was somewhat slower that it is today (and thus such flags had greater impact). Our conclusion back then was that the flags do technically make a difference, but the gain is so marginal in the wider context of things that influence system "performance" (esp. I/O performance) that it's not worth the effort. And then we killed off chipset specific builds. The idea (re)surfaces from time to time; mostly among the retro gaming crowd who constantly seek overclocks and optimsations, but (still) never seems to hold up to any real scrutiny..

The better place to post the Q would be in Kodi forums where the folks who code the PVR features hang out.

Perhaps enable persitent logging in the LE settings add-on and see what's going on. Then you can also retrieve previous system logs from the journal, e.g. "journalctl -b 1 --no-pager > /storage/old.log" to see if there are any clues (feel free to pastebin logs and share URLs).

popcornmix ^

Once the filesystem is unmounted you should be able to run fsck against it. From personal experience if you then cannot access the drive, it's usually because the drive has major problems (and it's time for a new drive). How many hours on it?

Using a cached EDID file might solve the first problem, it won't be part of the second. If you Google remote wake issues you'll find articles on setting USB devices as wake devices, and that might not be happening, in which case you can concoct a systemd service that runs when the box is suspended .. allowing you to wake again.

2023-02-12 14:55:34.538 T:3226    ERROR <general>: SQL: [MyVideos119.db] SQLite error SQLITE_CORRUPT (database disk image is malformed)

You'll need to delete the MyVideos119.db file and Kodi will boot again. If there's an older file it will be migrated and you can re-scrape the content added since. If that was the only MyVideos DB file you'll need to re-scrape from the start.

There are a couple of Meson8b (S805) device-trees. See what works most.

If the WiFi is still not working you need to connect Ethernet or do the textmode change I described before to get the boot log so we can see whether the device probes or not, or if firmware is missing, or something else.