Posts by chewitt

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..

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.

I'm watching Eurosport on an N150 device and the info overlay shows "vaapi-bob" is being used

LE will periodcally bump kernels to update drivers (which brings general fixes) but we're not aware of a frequently occurring issue and thus no need to take action fixing something.

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.

Quote from daniel712

I was trying to set up Youtube Addon on kodi with the API keys. It worked some days, but now with the nighly build it stopped working because inputstream something is not available...

The repo was bumped and it took a few days to chase down some compile issues. The repo should now be fully populated.

Quote from zeke2135

It also looked like I had to increase the startup delay to 45 sec to get the connection working completely.

If the RPi4 is on a wired network, that really shouldn't be required, and something is borked/wrong somewhere.

Start here: https://kodi.wiki/view/Settings .. click icons, learn how things work

The addons server is hosted in a Hetzner EU datacentre on a static IP address that has never changed, so the adult-content list is probably over-blocking on some wrong assumptions about the subnet or perhaps ASN that the IP belongs to.

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.

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.

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.

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.

ix.io is dead/down for some years now, so a working URL from our own paste server is the correct behaviour

Quote from Ubuntu_is_life

"***Error in mount_storage: mount_common: Could not mount UUID=d2f120b6[...]83 ***

The UUID is for the partition on the original USB/SD (or whatever you wrote the LE image to) and that UUID will change once things are moved to the HDD. So fix the boot=UUID and disk=UUID params in whatever bootloader config file is being used to ether use the correct UUID(s) or use LABEL or point directly to the relevant /dev/device(s) for the partitions.

K22/LE13 nightlies contain changes to the Kodi SMB client that might be interesting. First you can select SMBv2 without large MTU support (which likely isn't helpful to a remote connection). You can also fiddle with the SMB read chunk size; as smaller is likely to work better on a remote connection. It may also be worth experimenting with smbclient at OS level (locally mounting a remote filesystem using systemd mounts) instead of using the SMB client.

The Tvheadend server addon is also present since this morning https://addons.libreelec.tv/12.80.6/ARMv8/…ce.tvheadend43/

K22/LE13 supersedes all the advancedsettings.xml cache tweaking (that most users misunderstand and thus get wrong) with some sensible defaults and also reworks the SMB client. Perhaps update to a current nightly and see if that resolves issues.