Posts by chewitt

Railink and Qualcom (Atheros) devices are normally a good option, as the drivers are almost always in-kernel which improves performance, stability and support. Sadly Realtek devices are cheap so everyone buys them, but they are a pain to maintain and have more bugs/issues.

There is no official list. There will be no official list. Why? .. because we're a small team and we have many better (and much more interesting) things to spend our limited personal time on than generating innacurate lists of wireless dongle chipsets from manufacturers that fail to upstream support for their products to the Linux kernel. As most HTPC devices these days include a wireless chip that is normally supported (and using Ethernet with an HTPC device is strongly recommended anyway) it's also a declining issue. You may have other views, but that's generally the team opinion.

The skin might be at 1080p but you set the Desktop to 4K and the whitelist is not used so everything will be scaled to 4K. In other words, roughly the opposite of what I described. Kodi has to work on everything from Android phones to small embedded ARM boards, to high-end Intel chips. Hence it deliberately starts with neutral defaults.

Please take some time to read the Kodi manual Official Kodi Wiki

We manage 100% of the OS inside the KERNEL and SYSTEM files and it is not possible for "cruft" to accumulate in the OS because it's all contained inside a read-only (thus cannot be written into) file that is uncompressed to create a virtual filesystem on boot. You (and Kodi) manage 100% of the /storage area and this may accumulate thumbs, add-on installers, add-on caches, crash logs, etc.

Editing connman config files (service files) works if connman is stopped before editing and restarted after. Connman manages the files so if you do not stop > edit > restart connman can (and probably will) overwrite changes made at some point.

Some rough patches to address using an FQDN were posted to the connman mailing list about two months ago. I shared links to them at the same time and so-far received zero feedback. From this I conclude that nobody cares enough to contribute a little effort to testing. I blow hot/cold on my desire to do everything and have other priorities on my to-do list, so I suggest someone else pulls a finger out for once.

aptalca ^

Thumbs and other artwork are downloaded and cached uniquely on each device, but should use common URL references to the original art locations which are stored with the media in the DB, so it's inefficient (multiple downloads, multiple caches) but you should end up with the same art images on all devices.

If you enable a Wireless hotspot in LE settings you are hosting/creating a wireless access point (AP) and this prevents the wireless card from being used to join wireless networks; it can only do one thing at a time. Disable that and things should appear in 'Connections'.

mm_half3 nothing specific for that device, but you can experiment with the SM1 device-tree's in LibreELEC-AMLG12.arm-9.80.0-box.img.gz .. if you get anything working share "dmesg" output please.

malomehi pass-through audio is not supported in the current (initial) iteration of the mainline drivers so keep this disabled. I don't test CEC (it's not enabled in my AVR) so I have no experience with CEC, but I'm not aware of any issues.

Kodi only outputs progressive. In other words, 1080i does not exist, only 1080p. Kodi needs to render each interlaced half-frame as one real frame, so needs to use 1080p50 to render 1080i content. Do not whitelist 1080p25, do enable 1080p50 (and adjust refresh). Do not "sync playback to display" as that will force everything to be resampled and ARM devices are rubbish at that.

It's an RTL8821CU device, which means it's not supported in-kernel and would need a vendor binary driver. Unfortunately we have a long history of refusing to add these to the distro as Realtek breeds new chips on a quarterly basis and they tend to break with each kernel bump and are a pain in the rear to maintain over time.

Raspberry Pi OS uses X11 windowing and since it's a desktop OS there is support for multiple screen output and multiple player apps. LE runs a single app (Kodi) directly on the framebuffer so there is no windowing and we support a single HDMI connection. LE is more lightweight so will boot faster, but if you need multi-screen output and other apps, we're the wrong distro. NB: LE 9.2 still supports the original OMXplayer decoding, but MMAL will give better results over a wider range of media and is the default on 3B+ hardware. Kodi v19 dropped support for OMXplayer so it will not be present in LE10, but it will be superseded with GBM/V4L2 decoding, although this is still in development.

Sources solely define the locations Kodi can scrape to add new content into the Library (or can be browsed from the non-Library 'Videos' view). If you define sources on a box it can scan/update its DB, which in this case is a central/shared MariaDB instance. If you do not define sources, the device can only be used for playback of content that has already been added to the DB.

WiFi credentials are saved on successful connection only, so if you entered the wrong passphrase it will have failed to connect and nothing was saved. Go into the LE settings add-on and visit the Connections tab, highlight the WiFi network anme, click and select "connect" to enter the passphrase using the GUI keyboard.

The "install" script is checking for an OS that uses Debian packaging (Raspbian, OSMC, etc.) so it's not going to work on LE.

Share "journalctl | paste" about 60 seconds aftter booting (with Etthernet connected) and we can see what chipset is in the device, and from there we can advise on the chances of it being supported in LE.

Ahh, the original Q is now clearer. If you have two screens attached (LCD via ribbon, TV via HDMI) Kodi will use the first one probed by the kernel, and on ARM hardware Kodi does not support multiple screens output (maybe in the future, but not today). So to redirect output to HDMI, you either need to disconnect the LCD, or perhaps fiddle with config.txt and disable in software; I'm not sure as config.txt options are not my area of expertise.