Posts by chewitt

    Code
    info <general>: [display-info] make: 'Sony' model: 'SONY TV  *00'
    info <general>: [display-info] supports hdr static metadata type1: true
    info <general>: [display-info] supported eotf:
    info <general>: [display-info]   traditional sdr: true
    info <general>: [display-info]   traditional hdr: false
    info <general>: [display-info]   pq:              true
    info <general>: [display-info]   hlg:             true

    This ^ shows the Sony TV advertises HDR

    Code
    info <general>: [display-info] make: 'Samsung Electric Company' model: 'S95F'
    info <general>: [display-info] supports hdr static metadata type1: true
    info <general>: [display-info] supported eotf:
    info <general>: [display-info]   traditional sdr: true
    info <general>: [display-info]   traditional hdr: false  <= this is an old standard nobody uses
    info <general>: [display-info]   pq:              true   <= this is HDR/HDR10 as we know it
    info <general>: [display-info]   hlg:             true

    This ^ shows the Samsung TV also advertises HDR

    Code
    2026-06-16 08:45:50.124 T:765     debug <general>: [WHITELIST] whitelisted modes:
                                                       4096x2160 @ 24.000000 Hz
                                                       4096x2160 @ 23.976000 Hz
                                                       ...

    This output in both logs ^ shows you aren't following whitelist recommendations in https://wiki.libreelec.tv/configuration/4k-hdr although that's just an optimum config observation and not the cure for anything.

    Code
    debug <general>: LinuxRendererGLES::Configure: HDR passthrough: off

    This ^ appears in both logs.

    Kodi should be configured for "Adjust display refresh rate" (start/stop) with "Adjust display HDR mode" (enabled) and "Allow using DRMPRIME decoder" (disabled) and "PRIME Render Method" (EGL).

    Swordsmith is [email protected] but this res/rate combination doesn't exist on the DRM connector so the whitelist logic chooses [email protected] instead ^ and Kodi downscales the content (downscaling frames is easier than reducing the refresh rate). The NY demo file is [email protected] which matches an available 4K mode.

    I'm not aware of anything in the kernel/DRM layer that would block HDR metadata from being used. IMHO it's more likely that Kodi settings need changing (did "Adjust dusplay HDR mode" exist in LE12?) or it's something more basic like not having deep colour modes (or whatever Samsung calls them) enabled on the HDMI port that you're connected to on the TV.

    Stop Kodi, rename /storage/.kodi to /storage/.kodi-old and start Kodi again. You'll effectively have a clean install state. Copy back sources.xml and other config bits as needed. Or just delete the DB files and they'll be recreated.

    If you are trying to do backup and restore from the same device, use the backup and restore functions in the LE settings add-on to backup the files in /storage/.kodi|.cache|.config and nothing more is needed. If you have other files i.e. media on /storage to be backed up then it's best to create your own .tar backup from the original device so that all the file/folder permissions are retained.

    LibreELEC is permanently replacing the old network engine (ConnMan) with the industry-standard NetworkManager.

    No idea how you dreamed that piece of news up, but there has never been any internal discussion about changing from industry-standard ConnMan to Network Manager and thus there is zero plan to change in this distro.

    LE13 uses iwd instead of wpa_supplicant but that change was made in May 2023 so the same change is present in LE12 too, so not exactly breaking news.

    I don't have the bandwidth to investigate and attempt compatibility with the random vendor u-boot versions that Radxa and others come up with so the general rule is you'll need to exorcise vendor u-boot from SPI or eMMC to allow LE to boot its own u-boot from SD card and then install the image to internal storage. I'm not aware of anything that should prevent install to NVME storage but I don't have a 5B+ board to look into. You might need to look into the state of the upstream device-tree file; in the Rockchip universe core features seem to enabled ad-hoc/per-board rather than the all-boards approach taken with other SoC platforms.

    If you want the shows to appear in a Library view (under Movies or TV Shows) you need to properly structure files in folders so that scrapers categorise things correctly. If you just want to play them ad-hoc from the Videos view, then do what you like with them.

    Given that the original ROM is no longer available, I'm trying to determine whether there is still a practical recovery path.

    It's not impossible but serious experimentation needs physical and software tools and a deeper level of technical ability than most users have or will easily learn. It's typically rather time-consuming and bit of a hard slog, so even when the user is enthusiastic to have a go; most of the staff (self included) have learned to avoid such quests.

    ConnMan keys stores network profiles against the MAC address of the WiFi card so check the MAC is persistent. Some cheap USB dongles have none programmed so the kernel assigns a random address on each boot; resulting in the new MAC not matching against existing stored profiles and requiring you to enter details again.

    In the case of an RPi5 board it's more likely that the connection is bad as the onboard WiFi isn't great.

    Use LE13 ..

    Firmware can be added to https://github.com/LibreELEC/dvb-firmware or manually added to /storage/.config/firmware which is overlaid onto /usr/lib/firmware on boot.

    For drivers; someone should just "grow a pair" and have a go at upstreaming the driver bits required. It might some learning and a few iterations to get things into an upstream acceptable condition, but until someone does that (and sadly it looks like it will never be TBS themselves) you're all stuck in downstream purgatory.

    Kodi Piers (22) now contains some major changes to how Kodi handles GUI/video output on Linux. Most changes are addressing functional and feature gaps in GLES/GL rendering support. However they also cleanup older VAAPI code and fix bugs. I guarantee there are also more bugs to be found and hopefully fixed.

    In short: Kodi has changed. Users with configurations that previously relied on fallbacks/quirks/bugs may find their configuration needs to be adjusted as the dependent fallbacks/quirks/bugs have changed or no longer exist.

    Using D2P (as you were) is wrong for an Intel GPU device, it should use EGL. It's unclear if you were also trying to use DRMPRIME paths but that would also be wrong. Your old config was dependent on a load of fallbacks and quirks. Kodi settings needs tweaking to force EGL output and hide the wrong settings when using VAAPI .. it's on a to-do list.

    If you configure Kodi for 4K desktop with only 4K whitelist entries Kodi will upscale everything to 4K. If you configure Kodi for 1080p desktop and provide 4K and 1080p whitelist entries Kodi will scale anything under 1080p to 1080p and will render 4K at the native media resolution; this is generally considered "best practice" as Kodi is not modifying the original media (1080p and up) and most TV's are better at scaling 1080p to 4K than Kodi. Running a 1080p desktop normally means the GUI looks sharper and the HTPC device uses less CPU/IO resources resulting in smoother navigation.

    In summary: something in the Alpha state development release you are using has changed. You have been advised of a different and better configuration to use. You have confirmed that different and better configuration works. However you are unhappy at having a different configuration.

    "You can please some of the people some of the time, not all the people all the time"

    /shrug