When you say things are very-clear on the Free Guy movie; what is the frequency that the dropouts occur? .. because watching that movie I hear only a handful of audio glitches in the 2-hour movie. Again, from the way people have been moaning I'm expecting to hear something every few minutes to create a constant annoyance but that's not what I'm experiencing. To be clear, I do hear some glitches, but I want to ensure I have the same experience as others.
Posts by chewitt
-
-
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.
-
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.
-
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.
-
I've had thoughts about controller compatibility, but that wouldn't explain why something works when connected to a monitor and doesn't work when connected to a TV .. which (other than there being some magic aura around the monitor) honestly makes zero sense to me. I'm out of ideas
-
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.
-
Moved to off-topic as the forum is focussed on LE use-cases not requests for Android vendor images.
-
What nvme HAT are you using?
-
Change the default SAMBA_SECURE="false" in packages/network/samba/default.d/samba.conf to true, then create a clean install to test and I think auth will be enabled.
-
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.
-
Do you have PCIE_PROBE=1 in the eeprom config? - If no, boot from SD and add it.
-
-
That makes sense. Without the DVI source to reflect the (no audio) properties of when connected, the AVR either defaults to some basic defaults or advertising it's own capabilities, which you capture. And once captured the RPi4 always sees the same thing.
-
It's not possible to force SMB auth on via buildsystem options or Kodi advancedsettings.xml controls but we should probably change the defaults (within the LE settings add-on code) to do that as Windows has required auth for a while now.
-
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).
-
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:
Codemount -o remount,rw /flash nano /flash/cmdline.txt <= edit to add the video= lineIf 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.
Codemkdir /var/media/BOOT mount /dev/nvme0n1p1 /var/media/BOOT nano /var/media/BOOT/cmdline.txt <= edit to change boot paramsIf 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.
-
-
RPi5 boards will not boot from NVME devices without some additional configuration. If booted from LE on an SD card:
CodeRPi5:~ # 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 speedsNext you have to tell the EEPROM on the board to change the boot order:
CodeRPi5:~ # 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.
