Posts by chewitt

  • Supported SFP+ Cards

    As Linux dominates the server market where optical NICs are normal, it's unlikely that any NIC more than a year old is not supported in the kernel, although LibreELEC probably won't have the modules enabled.

    The CONFIG_NET_VENDOR sections define the top-level support for NIC families, but the defconfig is hierarchical and most vendors have multiple NIC families so when you enable a specific family; only then are it's options exposed so the defconfig is never showing you all possible options for all possible modules. If you know the specific NIC hardware tracing the config for it is simple. If you are working with hypothetical hardware it's not.

    Instructions on building an image: https://wiki.libreelec.tv/development/build-basics

    Then edit the defconfig to enable the module (uncomment and use =m) based on either looking at the file or some Google/GPT research on what's needed, then re-run the build command and the kernel will be rebuilt with the module enabled. Then tranfer the image to /storage/.update and reboot to see if it worked.

  • [RPi400] Memory leaks?

    The short answer is "no idea" and it's not guaranteed that what you see if the same as what I see. On my LE13 image there's 100% a bad leak, but I'm running a whole heap of experimental things that mess with DRM planes and buffers and I see the same leak on Amlogic and Rockchip (with the same patches) too. The fact nobody but you has complained before on LE12 is the main thing I find odd, as it's the kind of thing that would attract forum complaints.

    Either way, the LE13 patches need a load of reviewing and debugging and that's going to be my (Claude driven development) focus over the next week. Maybe that results in something..

  • Supported SFP+ Cards

    This is our kernel defconfig https://github.com/LibreELEC/Libr…nux.x86_64.conf

    Fibre NICs aren't a thing among our domestic userbase, hence there's probably little/no info on the topic, but that ^ file is where to cross-reference the NIC driver that's required for a specific device and whether it's enabled by default or would need to be enabled to work. Some NICs may also require firmware blobs but that can always be solved by dropping things in /storage/.config/firmware folders so they are overlaid on /usr/lib/firmware on next boot.

  • [x86] Videos playing in top left quadrant only

    See if adding video=HDMI-A-1:1920x1080M@60D to kernel boot params (change HDMI-A-1 to match the DRM connector used) solves the problem? - this will force the intial DRM state to 1080@60. As a general rule it's best to leave the Kodi GUI at 1080p and only switch to 4K when needed for playback, see: https://wiki.libreelec.tv/configuration/4k-hdr. I'll guess Kodi currently has a limit on the GUI being 1080p max but the desktop resolution or underlying kernel DRM layer is trying to use a 4K mode.

  • [RPi5] H.265 Stuttering

    If you are using the wrong presets when ripping or converting media, change the presets to ones that work on your hardware. If you are stealing the media off the internet and expect all the random encodings that have been used to work on all hardware; a) you will be dissapointed, and b) we don't care about that problem.

  • [x86-64] Dolby Vision a Possibility on PC?

    It's important to understand that DV is not 'a' standard, it's a collection of them. It is technically possible to implement support for all DV requirements on PC boxes. However there are quite a few technical barriers towards that happening. There are also a pile of legal issues. The technical requirements are slowly being chipped-away at, so there is full support for Kodi on Android (on licensed hardware that follows standards) but only partial support for Kodi on Linux; there are still things missing in ffmpeg and the Linux kernel DRM architecture and hardware-specific drivers. As a result there are many dissinformation threads from DV "experts" in forums that reflect the disconnect between their opinions on on how things work, and actual facts :)

    There is currently only one known open-source implementation of FEL 5/7 and that's in OSMC, and the term open-source means only that it doesn't depend on closed-source Dolby libraries. However this open implementation depends heavily on the Amlogic vendor kernel (with its own proprietary DRM architecture) and intentionally uses OP-TEE secureworld to prevent an army of Dolby lawyers from inspecting how it's been done, so the open implementation is effectively closed.

  • [RPi] Is it possible to pass through Atmos on a Pi4 or Pi5?

    Yes, Atmos and other HBR formats are supported on RPi4/5 hardware. You need to have Kodi in advanced/expert mode to see and enable AC3/E-AC3 pass-through as these are normally the transports for HBR audio formats. You also need a "certified" HDMI cable that can handle the higher bandwidth required. I'm also assuming the RPi connects directly to an AVR so that HDMI complexities like eARC support on inline TV devices aren't involved.

    NB: Aggressive/combative posts are not going to win you friends in this forum. If you want to rant, please go find some other forum to do it in. If you want actual help, use less pith and a friendlier tone, and focus on providing useful technical information about your setup, how you are testing something, and provide debug logs to support investigation.

  • [RPi] New setup - completely broken from start

    From a technical perspective timezone is a "nice to have" not "must have" function. The OS runs exactly the same on UTC as it does with one configured. There is also no need to define NTP servers; we fallback onto pool.ntp.org servers by default so as long as the network is functional, devices like RPi boards with no hardware RTC chip will have time corrected during boot.

    NB: Adding a timezone setup option in the wizard would be great. Our all-volunteer project staff working for fun in their free time looks forward to reviewing your contribution on GitHub to make that possible.