Posts by chewitt

You cannot boot the "wetek-play2" image from SD card without first erasing emmc (use emmctool from the box image) because if vendor u-boot exists on emmc the box always boots it and not mainline u-boot from the SD card. The boot partition on the SD card contains only extlinux.conf for mainline u-boot and this is not seen/understood by vendor u-boot; hence it cannot find legacy boot files. You can of course copy s905_autoscript etc. over from the box image but this replicates booting the box image from vendor u-boot which doesn't proove the issue with mainline u-boot is resolved.

So, erase emmc to force mainline boot from SD card. If the noise issue is resolved then it should boot. If it is not resolved, it will drop to the u-boot console where you can type 'boot' to continue booting. If you want/need to revert back to vendor u-boot I have a raw disk (dd) backup that can be downloaded and copied to /storage on the SD card and written back using emmctool again.

No idea

K22 contains some minor changes to the SMB client:

* Defaults to SMBv2 and large MTU support (not plain SMBv2)

* Defaults to 128k chunk size (and size is configurable)

The defaults were chosen by Kodi devs to work for the majority of people but perhaps your old router needs something different. Go experiment with options and see if that results in working connections again. I'd start with the minimum protocol.

It would be better to post on https://github.com/ampache/ampache/discussions

I might be missing something, but what has this got to do with LibreELEC?

garbear any ideas?

Anything on the UART output? (this is why it's kind of needed for these tests)

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.

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.

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.

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.