Posts by chewitt

  • [RPi5] Build process to get Kodi

    LE(13) and RPiOS use the same Linux 6.12.y LTS kernel source so you shouldn't need to touch that. All the mesa patches are long upstreamed by Igalia (on behalf of RPi devs) so just use a recent version. Kodi and ffmpeg still requires downstream patches, as you'll find in our repo. The various build options are in the package.mk files, as you found. Beyond that, I've little experience with compiling Kodi outside our buildsystem so I can't really advise.

    popcornmix does RPiOS not have an appropriately patched Kodi (and ffmpeg) version to use out-of-box?

  • How to get EXT4 drive to mount reliably?

    I was originally suspecting a power issue; especially if the drive is being powered from the USB bus, but when power draw is the issue I'd expect to see spurious errors in the log; mount failures or USB errors or .. something to indicate the device probed then trying/failing/trying/failing to mount and then eventually succeeding. Instead the log looks clean, as if the device is probed (once) and then mounts cleanly and correctly (once).

    If the device is USB bus powered, is it a 'single' USB cable or a 'dual' (Y) cable that takes power from multiple USB ports. SSD drives might be small but that doesn't necessarily mean they use little/less power - they can be hungry devices.

    Just for info, please run "lsusb -tv | paste" and "lsmod | paste" when the drive is connected.

  • 8440U , 28W Supported by LibreELEC?

    Benchmarks focus on "Which is fastest?" when the better question(s) are "Which is fast-enough for a good experience?" and "Which is best supported?" so they are not telling the whole story.

    e.g. RK3588 wins all current ARM SoC benchmarks but is only borderline usable due to incomplete software, whereas comparatively slow RPi5 is more than fast-enough and exceptionally well supported. Intel based hardware also scores big numbers but has been a lottery in recent years due to the never-ending drama from by LSPCON chips (and firmware) in the display chain.

    In short: Speed != Value

  • [x86-64] Blank screen when installed, live mode works fine

    XML
    <?xml version="1.0" encoding="utf-8" ?>
<advancedsettings version="1.0">
  <!-- enable debug logging -->
  <loglevel hide="false">1</loglevel>
</advancedsettings>

    First, create /storage/.kodi/userdata/advancedsettings.xml with that ^ content so Kodi is in debug mode for logs.

    Second, run "vainfo | paste" and share the URL.

    Now two things to experiment with:

    a) Force the HDMI connector colourspace profile to Broadcast RGB:

    Code
    systemctl stop kodi
kmstest -c HDMI-A-3 -P "Broadcast RGB=1" < /dev/null
systemctl start kodi

    Any different? - run "pastekodi" and share the URL again.

    b) Force Kodi to use the i965 driver profile:

    Code
    MESA_LOADER_DRIVER_OVERRIDE=i965
LIBVA_DRIVER_NAME=i965

    Create /storage/.config/kodi.conf with that ^ content, then reboot and run "pastekodi" and share the URL again. Also run "vainfo |paste" and share the URL.

    I'm not expecting to acomplish anything .. but we'll have more information to review.

    EDIT: 3rd thing: Do you have a DP to HDMI connector? .. i.e. connect to the DP socket not an HDMI socket. It would be interesting to see if that changes anything. I'm also wondering if the board has native HDMI connectors or internally they are DP with an LSPCON chip providing HDMI .. in which case have you ever updated the BIOS and/or LSPCON firmware?

  • [RPi5] Build process to get Kodi

    Code
    PROJECT=RPi DEVICE=RPi5 ARCH=aarch64 make image

    Or if you really do need to build an image .. start by building the current HEAD commit for either LE12 or master (LE13) branches. It all works. There is no need to muck about with package versions and patches.

  • [x86-64] Blank screen when installed, live mode works fine

    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?

  • OpenVPN Config Problem (PIA)

    Quote from Grasshopper

    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.

  • [RPi4] WiFi Issues on LE 12.0.2

    Quote from Can'tThinkOfOne

    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.

  • OpenVPN Config Problem (PIA)

    Quote from Reddirt

    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 :)

  • MySQL authentication success depends on interface speed

    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