I'm worried that since it always says AM or PM it's going to burn the letters into my OLED if I leave it on the menu by accident ..
Kodi uses the "Dim" screensaver by default, but you can switch it to "Black" instead, which gives you a black screen - nothing to burn in
I'm not sure why it's failing when the system was booting from the same SSD before. If the APPEND line in syslinux.cfg (on the SSD) shows boot=LABEL=LIBREELEC or boot=GUID=<long-guid-string> perhaps edit it to use boot=/dev/sda1 disk=/dev/sda2 instead. You can also try booting from an Ubuntu USB and using that to write the LE installer image directly to the SSD, then boot and run from itself (prob. called run from USB or such - it's years since I booted/installed Generic so I forget).
There are two YouTube apps in the Kodi repo; YouTube and Tubed - nothing specific for KidsTube. Any further discussion on them is best done in their respective add-on support threads in the Kodi forums.
Updated Chrome add-on(s) for LE10/LE11 have been pushed in the last day or so, they might need a while to appear on the repo.
LE11 is the priority now that LE10.x is done. There's a few things to resolve but it shouldn't be long.
run "kodi-remote" from the SSH console and you can navigate the screen to install the add-on?
If you are installing onto the LE10 Amlogic image that we've been chatting about in #IRC .. it will not work because the add-on repo is for LE 9.2 installations (Python2) not LE10 installations (Python3). You might want to look at Docker solutions.
The AMLGX images in https://chewitt.libreelec.tv/testing/ have experimental FFMpeg changes that improve seeking with HEVC media. It's not "fixed" but moves things from a 2/10 score to around 7/10 which is nice. I've also disabled the broken MPEG2 hardware decoder so content is software decoded. Linux 6.1.4 and almost final Kodi Nexus. NB: No change to G12A/B and SM1 support (still problematic).
cd /storage/.update
wget https://releases.libreelec.tv/LibreELEC-Generic.x86_64-10.0.3.tar
cd /storage
systemctl stop kodi
mv /storage/.kodi /storage/.kodi-old
rebootIf the current install boots/runs fine check the size of the boot partition. If it is ~230MB it's too small for a direct update to LE10 and you will need to figure out the install issue; hint, if you see the installer it's not a BIOS/EFI issue as it booted the installer. If it is ~512MB size the boot folder is large enough for a direct update. The commands above ^ download the LE 10.0.03 update file to the right place in preparation for a direct update. Then you stop Kodi, move the existing install files out of the way, and reboot to start the update. Once the update completes you will have a clean Kodi instance. You can then stop Kodi, copy essential bits of the old install from /storage/.kodi-old to /storage/.kodi (sources.xml, specific add-on settings, etc.) then restart Kodi to continue with setup. Rinse/repeat until things are as you need them again.
NB: Instructions saying you need to clean install for LE10 are not quite true. The OS and Kodi update with zero issues, but add-ons can cause major issues due to the Python 2 > Python 3 change. The process above avoids that by moving the old (and potentially problem) Kodi data including add-ons out of the way.
The "Generic" image should auto-detect the correct GPU, but audio card names will change so you'll need to revisit settings in Kodi to ensure things are selected again. I would not recommend an nVidia card unless your requirements are quite basic. Our mid-term plan is still to kill off the X11 image to focus on GBM and that still means no nVidia support (and under X11 there is no HDR).
If you already have Kodi up and runing all you need to do is create the autoexec.py file.
The TVs in the video are old devices without HDMI connections. The config.txt file on the RPi is only being used to force NTSC vs. PAL output on the Composite video output. That kind of modification in config.txt is supported only on RPi boards and only in LE 9.2 and older. In LE10 and up (LE11 is coming soon) video modes are forced with "video=" kernel boot parameters (params).
On a Raspberry Pi these are set in cmdline.txt, and you would append one of the following:
video=Composite-1:720x576@50ie <= PAL
video=Composite-1:720x480@60ie <= NTSC
RPi4:~ # cat /flash/cmdline.txt
boot=UUID=0602-0454 disk=UUID=a7ecf32f-d897-4f8e-b760-03d219e31c88 quiet video=Composite-1:720x480@60ieOn x86_64 hardware devices you append it to the APPEND line in the syslinux.cfg file in /flash:
NUC:~ # cat /flash/syslinux.cfg
DEFAULT linux
PROMPT 0
LABEL linux
KERNEL /KERNEL
APPEND boot=LABEL=System disk=LABEL=Storage quiet video=Composite-1:720x480@60ieIf you are creating something with an HDMI equipped device and you already have video output there is nothing to do - there is no need to force NTSC vs PAL (the concept doesn't exist with HDMI) and you only need to implement the autoexec.py part of the tutorial.
The terminal add-on in our repo allows you to access an SSH console from a browser. Or you can do things the normal way and use any SSH client from any OS. There is no terminal within the Kodi GUI at all, and no plan to ever add one. ChatGP is not infallable.
^ The driver is enabled in LE11 nightly images:
https://test.libreelec.tv/11.0/RPi/RPi4/LibreELEC-RPi4.arm-11.0-nightly-20230111-6d10ebf.img.gz
NB: LE does not support direct update from LE9.x to LE11. If you attempt it the update process should automatically fail but it's possible for users to override those checks. If you do that, the update *will* 100% break booting because the vendor and upstream boot processes are completely different.
If eMMC is wiped this image will boot from SD/USB: https://chewitt.libreelec.tv/testing/LibreE…etek-hub.img.gz and once LE is running and you have SSH access you can download the same image to /storage and write it to eMMC using emmctool.
If eMMC is not wiped and vendor u-boot is still trying to do some form of recovery the following are the factory update/restore images that can be loaded from SD/USB to recover the Android OS. These are not Amlogic burning tool images (which I don't have).
If eMMC is not wiped but vendor u-boot cannot recover things (is broken some way) the worst case scenario is to open up the box (screws are behind the foot pads) and short pins on the emmc chip to disable it. This prevents vendor u-boot (or whatever remains of it) from interfering in boot and effectively forces SD or USB boot; so you can use the AMLGX image I linked above. It works but most users feel uncomfortable about sticking screwdrivers on memory chips to short pins and it's best done with UART access so you can see what's happening.
In all cases, having the UART cable that WeTek shipped in the box connected so you can see what's actually happening and/or where things are failing is always a good move.