Posts by chewitt

  • Intel Alder Lake 2160p @ 23.976 Hz passthrough HD Audio dropouts (i7-1270p/N100)

    I've acquired a Beelink S13 mini (Alder Lake, N150) box for testing and have this connected to a Marantz AVR with 7.1 pass-through configured. I've been connected to both HDMI ports. I've not seen any video issues, and I've experienced only a couple of brief audio glitches when playing [email protected] + TrueHD media, but it's not happening often and the way folks have been moaning about things in this thread I was expecting something more frequent or obvious. Is the 'dropout' a momentary glitch or silence lasting a few seconds? - and what's the frequency of occurrence?

    I'm also interested if someone can share a media file that reliably triggers this issue with good frequency and duration, as my own test media doesn't seem to achieve much.

  • Official LE13 Test Images for Amlogic (Kodi-22)

    The HEVC decoder was never really finished so it mostly works, but some media files cause issues and give no output. S912 also has no support for DV so you won't get output unless media contains a normal HDR fallback stream; some does, but most of the content from online streaming sources does not (to save bandwidth). It's also hard to comment on what happened without seeing a debug log. In the current codebase playback is what it is until Amlogic get further along with upstreaming.

    Analogue output is likely a little under-developed given the focus on HDMI so no real comment on that. This wiki article should get the remote working: https://wiki.libreelec.tv/configuration/…ration-advanced - the generic q200/q201 device-tree files intentionally don't contain preconfigured keymaps so you need to define your own.

  • Official LE13 Test Images for Amlogic (Kodi-22)

    Quote from crazyazz

    I have a Mecool M8S PRO L with 3GB ram and 100 Mbit lan. Its working with the meson-gxm-q201.dtb file, but I only seem to have 2GB being used by kodi. Any way to update the dtb file?

    The upstream kernel doesn't have/need the complication of hardcoded RAM sizes in device-tree; it auto-detects whatever capacity the box has. So either the Amlogic (Android) u-boot code booting the box has been hacked in some way to withhold RAM from the kernel, or the box has 2GB ram and vendor u-boot/kernel code was hacked/hardcoded to show a fake 3GB value. The latter happens quite a bit on Android boxes from the GXM era, so IMHO is the more likely explanation. NB: Kodi runs happily on something with 1GB RAM so 2GB RAM is more than enough unless chasing an exotic configuration with lots of services running in the background.

  • Build with preset LibreELEC settings?

    There's some simple runtime logic for "if this doesn't exist on /storage, create dirs and copy from SYSTEM" so there's always the option to stash the QQ customisations inside the image and if e.g. /storage/.kodi/addons/skin.custom doesn't exist, unpack and create them without the user ever needing to transfer things over SMB. It would be quite simple to maintain customisations in a GitHub repo and add them to the image with a custom buildsystem package under packages/oem which works the same as the packages/virtual location. Also not complicated to check versions of things on /storage and use the same mechanism to update items statically instead of using an online 'repo' for things. In some ways LE is difficult because it's different. In others (and once you understand the mechanisms) is really rather flexible and simple.

  • Official LE13 Test Images for Amlogic (Kodi-22)

    I've not tried booting Hub/Play2 from each others images so can't guarantee that works. If you erase emmc so the board boots from SD card it's safe to experiment though. If you write the wrong image to emmc and there's an issue, it's not impossible to resolve but hope you like dismantling things and shorting pins on the emmc chips to temp disable them and boot from SD card again; as that's what'll be needed. I'm up to my neck in some Rockchip work at the moment, but test on SD card and if that works and you want the right image to write to emmc, I'll find some time to go build one.

    No idea on UART levels as I have a generic USB to DB9 adapter (cheap on Amazon) for those boxes. The only annoying thing is one of the cables WeTek shipped (can't remember which) is fema1e DB9 not ma1e, but that's solveable with a gender bender.

  • [RPi4] No HDMI audio on LibreELEC 10, 11 and 12

    Does the AVR have a TV connected to it too? If yes, switch the AVR to that output and see if audio works (it should). If yes, capture the EDID data of that source with "getedid create" over SSH and then reboot. The RPi4 will now see that TV and its audio capabilities as always connected. Now see what happens when you switch the AVR to the projector. Audio will either continue to work, or it won't.

    If there is no TV connected to the AVR the same thing can be done by going mobile with the RPi4 and connecting it directly to a TV somewhere to capture its EDID data. You need to run the command over SSH so might need to connect the RPi4 to WiFi if there's no Ethernet nearby. It's slightly fiddly to setup but not that hard to do, and tt's $free to test.

    RPi5 will be the same as an RPi4 board (and all modern hardware).

  • Kodi not seeing NVME SSD recognized in Raspberry Pi OS and formatted as EXT4

    The description doesn't make sense to me. However, in most cases when users report "device hangs on boot" or similar the OS is running happily in the background but for some reason the connected TV is not liking the current display mode resulting in a blank screen (hence the appearnace of boot hanging) instead of showing the Kodi desktop. That can normally be worked around by adding video=HDMI-A-1:1920x1080M@60D to the line of kernel boot params in cmdline.txt to force the initial kernel DRM output state to 1080p@60Hz which generally works.

    If SSH was enabled in the OS before it should be running so you can login to remount the boot partition in read-write mode and edit the boot params:

    Code
    mount -o remount,rw /flash
nano /flash/cmdline.txt                   <= edit to add the video= line

    If not enabled before, you can create an SD card with "ssh" added to cmdline.txt so you can login and mount the boot partition of the NVME drive to edit its version of the boot params in cmdline.txt, e.g.

    Code
    mkdir /var/media/BOOT
mount /dev/nvme0n1p1 /var/media/BOOT
nano /var/media/BOOT/cmdline.txt          <= edit to change boot params

    If the device is really not booting at all with an NVME related message on-screen, please snap a picture of the message with a mobile phone and share it here or upload somewhere so we can see it. If it's only on-screen briefly most phones can take a slow-motion video allowing you to replay and spot the message; either taking a still from the video or transcribing the text to share it long-form. In short; please share the message so we have a clue to work with.

  • Kodi not seeing NVME SSD recognized in Raspberry Pi OS and formatted as EXT4

    RPi5 boards will not boot from NVME devices without some additional configuration. If booted from LE on an SD card:

    Code
    RPi5:~ # mount -o remount,rw /flash
RPi5:~ # nano /flash/config.txt

dtparam=pciex1              <= add to bottom of config.txt
dtparam=pciex1_gen=3        <= optional, enables faster speeds

    Next you have to tell the EEPROM on the board to change the boot order:

    Code
    RPi5:~ # rpi-eeprom-config --edit

BOOT_ORDER=0xf416           <= change the BOOT_ORDER line to this
PCIE_PROBE=1                <= might be needed with older HAT devices (try without first)

    However, if the goal is to boot LE from the NVME drive, it needs to be configured with TWO partitions; one for boot files and one to be used as the persistent /storage area. If the drive is currently partitioned with a single partition and filesystem (containing some media) this is easiest done by copying media off the drive, booting LE from SD card, copying an LE image to /storage then writing it to the NVME drive using dd to effect a clean install; and then copying media back to the drive. Resizing and moving filesystems and partitions to avoid the need for moving media around can also be done, but it's not a trivial task to do from the console.

    If you are fine booting LE from the SD card and simply want to use the device as extra storage that's no drama. Run pastekodi and mount | paste from the SSH console then share the URL(s) generated so we can check the drive mounted correctly and see where it mounted within the filesystem; the usual location is /var/media/<label> if the drive is named/labeled or /var/media/<UUID> if there is no name/label and the UUID is used instead.

  • External USB hard drive not showing up in Libreelec.

    Your initial description implied the OS auto-updating from an older LE major version to LE12 and this is 100% not possible. LE (and OE before it) have never supported major version auto-update. I've also checked the update back-end that controls this and nothing has been misconfigured.

    Auto-updating from an older LE12 release to the current LE12 release is of course possible, but in this scenario the NTFS drivers do not change between releases (both use in-kernel NTFS3) so a difference in mount behaviour is unlikedly to be kernel/driver related and more more likely to be the result of a change in drive state; and the perennial problem with NTFS formatted drives (which is not an excuse and happens no matter which driver is used) is a dirty filesystem. The second most popular reason with external drives is the power/current draw on the USB ports/bus and that can be challenging to triage. You can try connecting to different USB ports; ideally placing the drive on a different internal hub to other USB connected devices. If the drive is not externally powered, also try using an external (powered) hub.

    If everything just magically works on an older LE release (using NTFS-3G) this implies the driver change that occured between older releases and LE12, but this is only possible via manual update which you are adamant didn't happen. Regardless; as mentioned in a previous post, you can revert to using the NTFS-3G driver by installing the add-on from the LE12 repo and rebooting.

    NB: Linux intentionally fails to mount at the merest hint of a drive issue to avoid potential damage. Windows generally makes every attempt to keep mounting the drive to keep data available and users happy, and rarely flags any problems until the drive just stops working completely. Hopefully that's not the case though. If you want any further comment run "dmesg | paste" on the LE12 system so we can see what mount failure message are in the system log.