Code
Options=username=xxx,password=xxx,rw,vers=2.0,uid=1000,gid=1000,forceuid,forcegidTry using lowercase params first, and if that still doesn't work, see if adding forceuid,forcegid works?
Posts by chewitt
-
-
Where can I find the list of devices compatible with the new version of Libreelec ???
Why doesn't a USB wifi skewer work in libreelec???
in coreelec it works without problems.List of device-trees in the upstream kernel is here: https://github.com/torvalds/linux…oot/dts/amlogic
And the probably cheap Realtek USB WiFi? (not sure what a skewer is) device works in CE because their kerrnel never changes so bundling a large number of poor quality realtek drivers that break and need new patches with every kernel bump isn't a big issue for them. In LE the kernel changes frequently and we got bored of the make-work involved years ago and stopped adding Realtek vendor drivers.
-
It was working till now with CoreELEC 9.X with dtb for Vontar T95Z Plus S912 3GB/32GB.
Please provide the dtb name that you've been using.
-
The usb_modeswitch changed was merged to LE since it's harmless and will be needed at some future point when the upstream kernels that LE uses gain support for that chipset. There is support for RTL8821CU wifi in the CE codbease (for Amlogic hardware only) that vpeter works on. There is also existing support for the BT side of the module in current kernels, which is why that works.
This set of changes should add support for WiFi https://patchwork.kernel.org/project/linux-…pengutronix.de/ .. but they are not merged and seem to be taking time. I would expect a couple more iterations of the patches before they get merged (and then we can pick them up or perhaps backport).
You can probably borrow the build-system package for the vendor drive that CE uses, and use it in a home-built LE image. We refuse to add the Realtek vendor drivers into our main codebase due to low quality and the constant need to patch/update the ever-growing number of drivers every time we bump kernels (which is frequent).
-
Some things I would try:
- Test with TVH 4.3 not 4.2
- Test the tuner on different hardware running the same LE release, e.g. x86_64
Logs showing at least the unusual boot delay would be interesting.
-
Code
[ 12.876758] meson8b-dwmac c9410000.ethernet eth0: no phy at addr -1 [ 12.876792] meson8b-dwmac c9410000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19)Ethernet works fine if the box follows the reference design. Not all boxes do. It would help to know what the box is? .. and if possible to get the Android device-tree file, or be told what device-tree has been used successfully with other distros like CE.
-
Patch the code so that both calls use g_memdup ?
-
I will have a copy of the file in a clone of the LE image archive (which is currently offline) but the 9.2 release images will be a lot more reliable than some early alpha build. Also, there will be no add-ons for that image now, becaus ewe normally delete the alpha content to save space on the server once final releases have been out for a while.
-
You can/could bastardize something in pulse to do this, but it will be complicated as hell to configure and prone to timing issues so I just wouldn't bother. Save pennies and get a proper HDMI 5.1 surround speaker arrangement. The result will sound better and be zero effort.
-
For unexplained remounting of drives I'd suspect either power, or perhaps running out of RAM causing processes to be killed/cycled which can result in things being in odd states (not specific to LE, but a general thing with any Linux distro). Enable persistent logging and then do some log review/reading.
-
LE10 (stable) and LE11 (stable but still pre-beta) images can do everything that LE 9.2.8 can do. Use them; they are greatly superiour than LE 9.2.8 now. If you have an issue with those images; state the problem.
-
It took me 10 seconds to find this in Google: https://forum.kodi.tv/showthread.php…4738#pid2484738
-
Kodi has no support for tonemapping and is unlikely to gain that capability anytime soon. Most hardware Kodi currently runs on either lacks the specialist image manipulation capabilities to do on-the-fly tonemapping, or the hardware can do it, but support hasn't been implemented in the Linux kernel and drivers yet; and hence there's no need (and not much point) trying to support it right now.
In simplistic terms: Kodi simply outputs video with an appropriate resolution, colour depth, colour-space, and HDR flagging as detected from the media being played and within the constraints of what the hardware (HTPC) can output. As not all hardware supports all combinations (read from the HDMI EDID data) Kodi will sometimes output in a higher bit-depth or nearest colour-space from possible output formats. It's then up to the display device (Monitor/TV/Beamer) to figure out how to display that combination.
-
Experiment with the connmanctl move-before/move-after options, as this will change interface priority and influence the routing table.
-
There is no support in AMLGX for the internal tuners - there is no V4L2 demux in the upstream kernel.
-
There's nothing enlightening in the dmesg log (as was expected). It's an odd one.
-
Please run "dmesg | paste" and share the URL, to see if there are any error messages in the log?
The one remaining experiment I can think of is writing the WP2 (not box) image to emmc. This replaces vendor u-boot with upstream u-boot and changes the early boot process. That said, I'm not sure it would resolve anything as I've not had other reports of what you're seeing and there's a growing number of users (most of whom are probably booting from SD card). I have a raw (dd) copy of the original factory image that can be restored to emmc if you wanted to put Android and vendor boot code back.
https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz
To install to emmc download the WP2 image to /storage/ and then run "emmctool w LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz" and it will install everything. To restore the backup, boot the WP2 image from SD card (so emmc is not in-use) and then download the backup and write it with "emmctool w backup-wp2.img.gz" .. until it eventually finishes.
-
LE fixes a kernel major version for a specific release and then sticks with it. So LE10.x is built around 5.10.x (on RPi at least) and on LE11 we're currently at 6.0 but will probably end up on 6.2 by the time we enter beta and lock the kernel version. There's no trick to it, or penalty for being on 5.10 in the current stable release. If you want to replicate our stability you'll need to replicate all the same major versions and the patches that we use; kernel, kodi, mesa, firmware, etc. - it's not just the kernel.
