Posts by chewitt

Quote from simonFFM

The Network Access Point Mode seems pretty unstable for me in this Beta. Do you already know that? Do you have the same bug? Is there a trick to solve the problem?

The main issue with the hotspot feature is user expectation. ConnMan provides a deliberately simple WiFi hotspot not a wireless access point. It is designed for tethering a laptop to a mobile phone. It was added to the distro by me so I could connect to Hotel WiFi and (via the hotspot) pass the WiFi password check to get the HTPC onto the internet and watch a movie via Plex. It works for that and similarly simple tasks, but it is not a network access point or router - if you want a router, get a router. The second issue is that RPi has a weak antennae which users often hobble further with cases that impair signals.

I'm not sure why the settings add-on would lose the region config .. but this is not used when running the access point (which has an internal harcoded config) and switching between hotspot/wifi modes may drop the setting.

4K60 support is still work-in-progress in LE10, it is one of the things being actively worked on, along with 10-bit/12-bit support which is inter-woven with the same topic.

You can use overlays, but these are compiled files so you cannot add a text file and use it. You need to make a kernel patch to add the overlay to the kernel (and compile it) and then include the overlay in the list of overlay files that are copied to the image. Then you can add the overlay to extlinux.conf and use it. There is plenty of prior-art for that in the Allwinner build-project.

Enabling EXT4 filesystem encryption config results in a kernel that supports EXT4 encrypted filesystems. You would still need to modify LE to use an encrypted EXT4 filesystem within the squashfs SYSTEM file. Adding fscryptctl adds a tool to manage encryption, but since this tool is inside a read-only file (SYSTEM) it will not be able to modify the active SYSTEM file. Making LE boot from an encrypted SYSTEM file is probably not impossible (but there is no how-to, so don't ask) but I wouldn't see any advantage to that approach over using sky42 images which can provide encyption to /storage where you can place any sensitive binaries/configuration/content.

Nor has it ever been stated that we will not have deinterlacing or that deinterlace is not important. There is just a finite amount of developer time, and that time is currently busy with figuring out 10-bit/12-bit plumbing and how to deal with some of the more base functional issues that we're seeing now that RPi4 (on V4L2) user numbers have ramped up.

There is a "Keymap" editor add-on in the Kodi repo. You can use this to remap keys and functions.

Too-Lazy/Didn't-Read, i.e. the short answer.

You have banned add-ons installed. No further support until evidence of a clean system is provided.

You have banned add-ons installed. No further support until evidence of a clean system is provided.

You have banned add-ons installed. No further support until evidence of a clean system is provided.

Computers

It's odd. If you don't set any NTP servers via the LE settings add-on or connmanctl, connman will fall back to the embedded defaults which are some standard pool.ntp.org servers.

Dropbox - bootsector.img - Simplify your life

^ Write that file to the SD card and it will destroy any partitioning in the bootsector, so the card can be repartitioned from scratch.

RPi Foundation need to support a large and diverse range of devices that until RPi4 were all 32-bit. To keep things simple during initial bring-up the kernel driver support for RPi4 (which is 64-bit capable) was kept at 32-bit. Now that development has shifted from hoarding a huge collection of downstream patches for a 32-bit kernel to upstreaming everything to 'the' kernel, it's increasibly viable to run a 64-bit kernel, but it is less tested and proven. For LE's use-case a 2GB RPi4 is fine, so while the majority of users purchase the 4GB model (and a minority the 8GB) there's no real-world need for LE to run RPi4 with a 64-bit kernel and the RPi Foundation would prefer we used the 32-bit version until they finish porting/upstreaming drivers. In many other ARM SoCs we support the kernel is only available as 64-bit so that's what we use; but we use 32-bit userspace with all ARM devices to leverage libwidevine so users can watch software decoded Netflix and Amazon (as there are no 64-bit libs). On RPi4 YouTube (via Kodi add-ons) plays 1080p H264 hardware decoded already so there's zero advantage from using 64-bit software decoding.

TL/DR; You aren't going to make a eureka discovery of some RPi4 performance/optimisation trick we (or the Pi Foundation devs) missed.

The proxy in the Kodi GUI does work, but it will only proxy communications made by Kodi itself, not by Kodi add-ons which make independent connections. It's not working as you expected, but it works as designed, so there is no bug to be fixed.

The description sounds [sic] like the high-pitched pops that I heard on Amlogic until I ditched the experimental HDMI pass-through patches.

It's rare (mostly seen with older HDMI-dongle devices that need 32-bit boot firmware) but some BIOS are funny about syslinux on HDD (but fine with it on removable media) and you might need to use a different bootloader, e.g. GRUB. The syslinux and GRUB boot config file formats are quite similar so it's normally fairly obvious how/where to copy-paste the kernel boot params we use. You can also experiment to see if GPT partitions (not MSDOS) show up.

GitHub - librespot-org/librespot: Open Source Spotify client library <= there's some references to installing librespot via cargo here. The LE add-on is packaged to work only on LE so isn't going to work on OSMC or other Kodi using general distros.