Posts by chewitt

I have a modern TV which supports 1080p @ 60/59.94/50/30/29.97/25/24/23.976 modes, but only 720p @ 50/60 Hz. As 99.999% of the movies in my collection are 23.976fps the playback experience will be better with 720p upscaled to 1080p where the fps/Hz rates will result in an exact match.

However, if all the media is e.g. downloaded BBC iPlayer content at 720p@25/50 then I would also have an exact match with the 720p modes on the TV; and then I would need to compare upscaling done by the TV to upscaling done by Kodi .. and this is always going to be subjective to what I think it better, and how good my TV is at the task, i.e. my TV might be better than your TV (or vice versa).

TL/DR: Only you can answer the question. Go test

Merged

I'd test with/without the clm_blob as those are 100% implementation-specific and can cause issues on the wrong board; and it would not surprise me if Radxa blindly copied the files in their repo from somewhere like Armbian (look mum it works.. job done). I'm also unsure that brcmfmac supports the same naming overrides for clm_blob as the bin/txt files? (something to test).

I'll also comment that "newer is not necessarily better" as Broadcom (like all SoC/chip vendors) fork code for each new customer project; creating the opportunity for all-new and exciting bugs that don't exist on previous/older forks previously created for a different customer. It's all under "version control" but the process isn't what you wrongly assume it to be

NB: This has been lurking on our repo for a while https://github.com/LibreELEC/brcmfmac_sdio-firmware/pull/30

I have fuzzy memory of testing the files on an Amlogic S912 board when it was PR'd and it broke WiFi so I didn't merge; but I should probably go back and test again. The problem with these files is - they are all supposed to be board-specific which makes packaging for a generic distro a "choose your compromise" game.

I guess the question/responsibility rests with hifiberry folks. Do they want to broaden the market for their boards to other fully pin-compatible SoC platforms? .. which probably gets a Yes/No answer. They're small enough that more sales would be great. Equally they are probably so focussed on Raspberry Pi that they're unsure what anything else might entail for long-term support and that might result in an over-cautious no response. The only way to find out is making contact and asking them. In reality it's probably a small change and pushing something upstream: and in parallel pushing the update to RaspiOS so the required overlay changes are already in-place when the upstream change flows downstream in some future kernel bump.

Entirely up to you if you want to ask them and advocate, but I'll always encourage that kind of thing to happen. The RPi kernel devs are sending more things upstream than ever before, but the pile of technical debt is still large. Hence all help in reducing it is good and .. no worse opinion of anyone for finding something easier to do

Quote from Rataplan626

I'm really sorry for my compile noobness, but how do I check?

"git show <hash>" should output the patch content if the upstream kernel hashes have been merged correctly into the downstream Raspberry Pi kernel source that we use with RPi images. If they haven't, that will error and you'll have to search (grep) the commit log to find the commit message and confirm the patch is present.

Direct firmware load for brcm/brcmfmac43456-sdio.radxa,rockpi4b.bin failed with error -2
Direct firmware load for brcm/brcmfmac43456-sdio.clm_blob failed with error -2

^ Those are harmless messages; the driver looks for board-specific firmware/nvram files before falling back to generic files, and it's rare to see any devices have clm_blob (board-specific performance tuning) files available.

Your board will be using generic files, so there's two things to try:

a) Update to a current LE12 nightly so you're using a recent kernel that may have driver fixes.

b) Some boards need specific firmware/nvram config as generic files cause problems. So I'd have a look in Radxa GitHub repos (or Armbian) to see what they ship with that board. If you put the files in /storage/.config/firmware/brcm/ with the filename brcmfmac43456-sdio.radxa,rockpi4b.bin (firmware) and brcmfmac43456-sdio.radxa,rockpi4b.txt (nvram) and reboot, they will be used instead of the generic files. If that fixes the problem point me to links and we can add them to our images.

Otherwise it's not something I've seen before with Broadcom modules. It does happen with cheap Realtek USB dongles where the manufacturer was too lazy to get unique OID's for their devices or programmed everything with 00:00:00:00:00:00.

Congrats

The ideal thing would be for the i2c/i2s bits to be obtained from device-tree allowing a common driver module to be upsteamed to the mainline kernel with minor device-tree changes (applied through an overlay) providing the runtime differentiation between RPi and RK (or any other compatible) SoC type.

Quote from mr.mister123

Any ideas?

Remove any config.txt changes and the edid bits from cmdline.txt and update to an LE12 nightly, then test again. There are specific fixes for display issues and LE10 is no longer maintained.

Is this patch in the kernel source? https://patchwork.kernel.org/project/linux-…foundation.org/

The DVB module drivers are disabled in all LibreELEC images because the (multiple) driver sources we used to include were never updated within months of a major kernel bump and over time became more and more unreliable to use/include. We now support only DVB cards with upstream kernel support.

Map the "AudioDelayPlus" and "AudioDelayMinus" actions to buttons on the remote keymap and it should be possible.

There's no concept of sideloading in LE. You can either self-build an LE image with the Python bump reverted, or rework the SSL bits around newer Python, or route requests through some kind of reverse proxy so that LE > Proxy uses modern TLS and Proxy > Site uses older ciphers.

I'd guess that auto-discovery uses UDP broadcast so anything on the same switch or subnet can receive that traffic and show the server(s) available. However Kore needs to make a direct TCP connection to Kodi for control, so if e.g. a VPN connection is active and configured to "route all traffic" (noting the problem in your previous post) that connection will be routed down the tunnel and will fail. If that's not the issue, you need to share IP/subnet and routing table info for the Phone and the HTPC.

HDMI splitters have the advantage of being somewhat universal so if/when you update the RPi3B to something newer (which likely still has a single HDMI output) there's no change to the arrangement whether it's RPi or some other SoC/hardware. That said, HAT devices can be "recycled" with e.g. RPi5 as the GPIO pinout on RPi5 remains the same as RPi3 so if you go that route the update path is limited but you can still reuse. The main question to figure out for yourself is how much or little you want to spend?

Using an overlay is probably the "more technically correct" way to do things but I wouldn't worry about that until you have a working set of changes. Patching the kernel source will have an easier dev workflow as you figure those changes out.

It's been a while since I used a VIM3L for anything but the general state of the AMLGX image on SM1 boards should be the same as for G12A/B and I use an N2 (G12B) as part of my test regimen. If you read current LE11 release notes there's a long explanation of the general state of Amlogic things (LE12 doesn't change much). If you need 10-bit HEVC media (or 4K) then CE will be more feature complete, but if your media collection is more simple (mostly H264 and 8-bit HEVC, some VP9) then AMLGX can be an option too, and I see a slow but steady increase in users on "newer" Amlogic boards running AMLGX these days.

Official LE12 nightlies are a little behind my test branch (will be updated once some visiting relatives go home and I have some time to spend on it). Until then https://chewitt.libreelec.tv/testing/LibreE…as-vim3l.img.gz is available if you want to experiment.

I made a mistake when updating the image last time so the firmware file wasn't included. If you update to the same file again, this time it has the firmware inside. Then share a log again.

Kodi feature requests should be made to Kodi developers via the Kodi forum.