Posts by chewitt

    Linux normally mounts filesystems read-only when problems are detected; we don't want to write data to already damaged disk structures as this may make problems worse. Mount the drive to Windows and run dskchk.exe to clear the problems, then eject the drive properly.

    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.

    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.

    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.