Posts by chewitt

  • Radxa X4

    Posts edited to remove all the advertorial content. The second post was completely unnecessary so deleted.

    In terms of thoughts, it looks interesting: decent overall specs although most users will want emmc flash onboard which is promised but not shipping yet. There is one outstanding DRM bug affecting N100 devices that Intel devs are being rather slow at, but overall it should require nothing to be supported with LE.

  • HDR content freezes/ unable to play

    Da Flex all of those 'errors' are normal and harmless on Amlogic hardware. The bootloader being un-aligned is just a quirk of the platform. Amlogic hardware has no separate power regulators on the Mali chip (as the SoC was designed not to require them) so the kernel (correctly) reports they are not found on every Amlogic board. Broadcom WiFi clm_blob files are board-specific tuning files and the only boards in LE's entire line-up that have them are RPi boards, so all other ARM SoC devices with Broadcom WiFi chips (Amlogic, Allwinner, Rockchip, etc.) also fail to load them and report that error.

    mr-bledi The one issue that I can see in logs is this:

    Code
    2024-07-19 10:13:58.522 T:904      info <general>: [WHITELIST] Searching the whitelist for: width: 1920, height: 1080, fps: 59.940, 3D: false
2024-07-19 10:13:58.523 T:904      info <general>: Display resolution ADJUST : 3840x2160 @ 60.000000 Hz (16) (weight: 0.000)
2024-07-19 10:13:58.534 T:904      info <general>: CDVDVideoCodecDRMPRIME::Open - using decoder V4L2 mem2mem VP9 decoder wrapper

    The log is not a debug log (so missing a load of useful info) .. but that shows 1080p 59.94 VP9 media being upscaled to 4K@60 which Kodi will struggle with on an ARM SoC device. Kodi needs to scale the media 4x and also handle the mismatched refresh rate.

    However that shows an underlying issue with fractional rates (they are all missing):

    I've previously created https://patchwork.freedesktop.org/patch/573860/ which is now merged in the kernel. However including that patch now seems to cause fractional rates to go missing - If I revert that kernel change 23.976, 29.97, 59.94 rates are restored to the list of detected resolutions. However that won't help with playback, because then the original problem with 59.94 rates reported in the patch will resurrect itself. I'd guess that something else changed in the kernel, but right now I don't see anything obvious, and I don't have free time to bisect and find the breaking change at the moment.

  • Playback is stuttering after Pause

    Quote from sam-y

    Can the problem occure when some special x264 settings are used?

    Well, yes it's entirely possible to encode things with settings that result in problematic media files, but more likely it's about refresh rates and the lack of modes on the TV. Connect the playback device to another TV with those modes and .. be amazed that problems magically vanish.

  • Installing LibreElec on SSD

    I recently swapped an RPi5 from SD card to an NVME drive to see what the fuss was about (as I had a spare drive, and there are lots of cheap HATs). It boots a little faster, and it scrolls in large menus a little faster due to the better small file I/O performance, but I'd put heavy emphasis on "little" faster. It is a marginal gain and not some huge leap forwards. TLDR: Yes it's better. No you're not missing out if you stick with an SD card.

    NB: LE is rather lacking in proper NAS features, so as long as you regard it as "something that shares files" and not "something that protects your data" (esp. if running from an SD card) .. you won't be disappointed.

  • LE11/12: CIR Stops Working after Upgrade

    From the problem description it's sounds like a kernel issue, so triage needs to involve building custom LE images with kernel changes that attempt to pinpoint changes to the nuvoton driver. The normal git bisect workflow (on the whole kernel) will be challenging to do as rolling back to a much earlier kernel requires more than just the kernel githash to be changed in the LE buildsystem, and you'll end up going down a rabbit hole of changes. I would instead see if there are interesting looking changes that can simply be reverted to see if anything has a positive impact.

    This is the history of the driver: https://github.com/torvalds/linux…c/nuvoton-cir.c

    If you are sure that problems start around the 5.x to 6.x transition we have to look back some way. Most of the changes look not related and harmless. The first one that sounds a little interesting to me is https://github.com/torvalds/linux…e6233beadc650c4 but to set expectations, I'm not a code guru.

    However, to illustrate the process and test the theory I would git clone kernel sources and then revert that specific change with "git revert 4345e2e5c75895232a17e6783e6233beadc650c4" .. and if we are lucky this will revert cleanly. If it does, you can then do "git format-patch HEAD~1" to create a diff patch of the revert commit and copy the patch file to packages/linux/patches/ in the LE buildsystem. If you now respin the image, the buildsystem will detect the patch and only rebuild the kernel package with the patch applied, and then you can test the image. If the git revert fails, it's because there are other changes to the same code area since that commit, then and you need to revert the commits that touch the code in reverse sequence, and that will either be a relatively simple task with a couple more steps (and generating a few more patches to copy/respin/test) or it'll be a huge challenge. The nuvoton driver doesn't look like it had that much real-world change in recent years though, so I have a hunch specific commits will be okay to revert and test. No promises though.

    The problem description shows you have a moderate level of Linux skills (enough to compile images at least) so hopefully you might have half a clue on what I'm rambling on about :)

  • [RPi4] Out of Memory Error

    I doubt it's a memory leak, but without understanding the configuration of the device in more detail it's hard to comment. NB: If the problem is a leak then a 2GB or 4GB device will not fix the problem, only delay the failure.

    Run "pastekodi" and "pastecrash" and share the URL's generated.

  • [RPi5] Trying to get bluetooth remote "OK" button to send an "ENTER" code?

    Code
    echo "evdev:input:b0005v0508p1980*" > /storage/.config/hwdb.d/99-UR02.hwdb
echo " KEYBOARD_KEY_c0028=enter" >> /storage/.config/hwdb.d/99-UR02.hwdb
reboot

    ^ That would be the correct format for a hwdb entry based on the info shared, but if the OK key is listed in evtest and can wake the RPi from screensaver I don't think that's the problem. One of the BT remotes I have needs a hwdb file creating to make the enter button work, and without the file is does absolutely nothing. No harm in experimenting tho. Worst case it does nothing and you can delete the file again afterwards.

  • [RPi5] Trying to get bluetooth remote "OK" button to send an "ENTER" code?

    Reboot. Once the home screen shows, SSH in and run"journalctf -f", then fiddle with buttons on the remote so it reconnects; which should be visible and obvious in the journal. Once the remote is connected, run "cat /proc/bus/input/devices" and you should now see the input devices registered by the remote. I think the current issue is simply that when the RPi5 is booted the BT remote is not automatically reconnected (until you press buttons) so there is correctly no input device listed.

    True ??

  • RPi4 LE12 connects via WIFI and LAN but only via LAN it connects to shares

    I think you need to increase the "wait for network" timeout value in the LE settings add-on from the default 10s? to something like 30s. If the device is LAN connected this has no impact on startup time as the network is up before Kodi starts. If the device is WiFi connected then the kernel drivers load fairly quickly but some access points (routers) take longer to associate to, so Kodi needs to intentionally wait (longer) for the network to come up before trying to connect to MariaDB/shares. Kodi only tries to connect once at startup and if the network is not up the connect fails and Kodi defaults to local sqlite DB files (which are empty).