Posts by chewitt

    The limited number of resolutions/modes suggests to me that you're hooked up to a monitor? .. which is flagging some warnings about EDID data. Most devices flag some kind of EDID warning, but this is showing unusual ones for primaries/quantization which are related to colour .. and you're reporting weird colours.

    If you connect the device to another HDMI device (ideally a normal TV) is anything different?

    How does invalid date get updated/corrected in crl?

    It cannot be, hence the problem. The only way to avoid this is not fcuking up your certs with incorrect dates in the first place; then if or when you need to revoke them in the future the revoked certs have valid dates.

    Thus the suggested workaround is to remove/disable the CRL function in the OpenVPN config. It's a bad workaround because CRLs have security purpose, but you have no alternative.

    my home is MESHed and signals are decent so may not help.

    MESH signal strength is decent when measured from devices that have good antenna's. RPi boards have rubbish antenna's so the assumption may be invalid. Lots of random issues magically go away when WiFi things are moved closer and/or people give up and move to an Ethernet connection.

    The system log shows that Kodi starts before the network is up so background checks Kodi does on startup might prompt the "no route to host" error. WiFi connections are often slow to come up so you might need to increase the wait-for-network time in the LE settings add-on.

    The connection manager (ConnMan) is configured to prefer Ethernet over WiFi, so if Ethernet is connected and the interface has an active IP address, Ethernet will be the default route. You can also have a WiFi connection active at the same time but this will have a lower interface priority and will not be marked as the default route.

    I see this is a PIA issue so I contacted them. I found this issued has been around for some time so maybe it's time for them to correct it.

    I'm not sure it will be fixable. The CRL function in OpenSSL is an important part of the overall SSL security scheme and the certs that were revoked have bad dates (it could even be the reason they were revoked) and preventing the use of revoked certs is normal and correct. However OpenSSL also validates the dates in the certs and thus (also correctly) shows an error. It probably requires a code change in OpenVPN to downgrade the cert error to a warning if the bad cert is a CRL cert, but that kind of change will be politically complicated to get made, and then you need to persuade distro maintainers to adopt an arguably weaker security configuration as the default for their OpenVPN package to not inconvenience only-PIA users. I would expect most maintainers to middle-finger the idea on principle, so I doubt that will ever happen (and PIA will know this, hence the inaction on the issue).

    Wireguard is so much nicer than OpenVPN :)

    The problem is local to your network or hardware and is not a general issue. I'm highly confident of that due to a) using RPi4 and RPi5 boards myself to connect to a Synology NAS over Gbit Ethernet (both on the same Gbit switch) without issue, and b) the large number of daily active RPi4 installs and no other users reporting similar issues.

    Suggestions:

    • Update RPi4 firmwares
    • Use different switch ports
    • Use different cables
    • Test an LE13 nightly

    There's enough upstream in the kernel and u-boot to start exploring an image. There's also an existing pull-request on GitHub to add support that needs updating and rebasing; the unknown being when Kwiboo will get around to doing it. I've also asked some of the usual vendors to send me board samples, although so far I've had zero response which is a little disappointing.

    Yup, as already stated in post #2 you cannot do this without building a custom version of Kodi with forced rotation baked in. Kodi needs to be able to read DRM properties to understand that rotation is required, and then needs to render the UI rotated to match the prescribed orientation. Kodi does not do that currently, so the patch is required to force change.

    I've not seen reports of "Invalid Password" from other users except when wifi the passphrase is either wrong or contains illegal characters. There are also long-running reports of an "Invalid Key" error which is influenced by a large number of things; but the main one appears to be wireless signal strength, and RPi boards often suffer from poor signal due to the less than brilliant onboard antenna. RPi4 and RPi5 have different wifi chips and antenna layouts so can behave differently from the same location.

    I've no idea what the "no route to host" issue is caused by. Please put Kodi in debug mode, reboot and then replicate the issue, then SSH in and run "pastekodi" and share the URL so we can see Kodi and system logs.

    The OpenVPN config PIA distributes implements a Certificate Revocation List (CRL) check for security reasons, but the CRL data they embed in the config contains invalid dates and this causes connection failures with OpenSSL 3.3.0 or newer. Our master branch (LE13) bumped to 3.3.0 in April 2024 and is currently on 3.5.0, while the LE12 branch is currently on 3.2.4 - so I would assume you have moved from LE12 to LE13 and this introduced the issue.

    See https://github.com/openssl/openssl/discussions/24301 - according to posts/reddit threads linked from that discussion thread the workaround is removing the <crl-verify> section from the PIA config.

    Attempting to support a range of nVidia card generations is a complete clusterfcuk due to different drivers and their wildly different and incompatible dependencies. The latest generations over cards are starting to converge on the open-source standards used with Intel/AMD; and that's likely to force a decision to support only those cards. I've been experimenting with nouveau, but I keep finding issues which appear to be long-running and unresolved so I'm not seeing that as a good and reliable solution.

    The /storage/logfiles directory is not a persistent log storage location. It maps to the \\LIBREELEC\Logfiles Samba share and a zip archive of logs will be auto-generated when the Samba share is accessed over the network. If you have not accessed the Samba share from the network there will (correctly) be no files in the directory.

    Run "journalctl | paste" and share the URL generated so we can see the system log (Kodi debug logs are unlikely to be useful).

    I don't think it's Kodi, but possibly hardware related

    You're not sharing a Kodi crash log so I have to assume Kodi didn't crash; and the debug log shared doesn't contain anything that stands out. However if as you suggest Kodi is not to blame and it's something lower level causing the issue, that won't ever show in the Kodi log anyway. For that reason you need to share the system log.

    Subtitles are broken on Amlogic devices that use a Mali Utgard GPU (all GXBB, GXL and GXM boards) due to changes in OpenGLES shaders that Kodi uses. The developer who made the breaking shader changes (Sarbes) is aware of the issue caused, but he doesn't appear to be doing anything about un-breaking things either.

    I assume Allwinner/Rockchip devices are also impacted as some of them also use Utgard GPUs, although I've not seen user reports.