Good afternoon. I installed LibreELEC 9.2.6 on the raspberi zero W, bad cable and HDMI-CEC did not work, I can not connect a keyboard / mouse, at zero W there are no full-sized USB ports. How to enter SSID/password WIFI when booting the OS?
Fix the bad cable, then CEC works and (as previously described) the first-run wizard has the WiFi settings. Software complexity is never a fix for shoddy hardware. If you want a hardware solution, connect a UART cable to the board.
FYI, the default (embedded) time servers are 0/1/2.pool.ntp.org so there is no need to configure ntp.org servers, it doesn't achieve any real-world difference to the system.
NTP is being blocked somewhere. See if setting the router IP as the NTP server works, some routers will give a response to requests.
It's definitely a backup of my WP2 box, and I can boot the box image from the original vendor u-boot.
Any info on how to create functional dtb for rk3318?.
Creating a functional dtb will be trivial once someone writes a functional kernel for RK3318. The horse needs to come before the cart.
Martin has been implementing the HDMI driver and audio support. There is progress, but it's slow progress. `Development reached the point where some of the retro-gaming distros which don't have such a dependency on audio/video things are now using the upstream codebase.
You can try the "box" image here https://chewitt.libreelec.tv/testing/LibreE….0.1-box.img.gz the dtb to set in uEnv.ini is "meson-sm1-h96-max.dtb" .. but this assumes your H96 Max is the same as the box I made the device-tree file (which is a gamble .. it's a clone). HBR audio should be working fine but video is in a rough state in the upstream kernel so CE is probably a better option.
I assume you mean for RPi devices? .. it's in the Pi Foundation to-do list but not with a high priority.
NB: Until the audio channel mapping issues are figured out users can select the "HDMI" device as a pass-through device but should still select the "Analogue" output device as the main Kodi output. The Analogue PCM device alsa conf has some channel remapping to workaround the problem - the HDMI device does not support this.
LE uses pulse audio for BT output. It is probably possible to pair multiple BT audio devices and configure pulse to send L and R audio streams to the two different devices. However, how exactly you do this is the unknown. There is no HOWTO guide in our Wiki and nobody on staff has muh expertise in pulse audio, and you'll discover it's a complete bitch to Google for hints due to the massive number of false hits on common terms.
Boot this image on an SD card https://chewitt.libreelec.tv/testing/LibreE….0.1-box.img.gz and from the SSH console write this image https://www.dropbox.com/s/tw6bg3kipc8t…wp2.img.gz?dl=0 to eMMC with "emmctool w backup-wp2.img.gz" - the image is a raw backup of eMMC from my WP2 box before installing LE (or in my case, erasing Android).
I'm happy it works, but that configuration makes no sense. If you set min1/max3 the Kodi SMB client will choose the Samba smbclient default dialect which is SMBv2. The client can auto-negotioate to newer SMBv3 but it cannot negotiate down to SMBv1. The only way to make it use SMBv1 is to set both min/max values to SMBv1.
Is there any chance that upcoming changes will fix the analog audio output (jack)?
Unless these changes are already implemented?
It's not something I've tested but AFAIK it should be possible to use it with the correct mixer settings. GXM devices use a common "toacodec" driver and everything needed in device-tree should be present and connected - not on the Minix boxes that have a different DAC chip. It may be something that needs work in alsa-ucm to make the process a bit more friendly. Once we get the current 44.1/48 issue resolved and merged I'll switch testing to a GXM box with an audio jack and see if it can be figured out.
ConnMan owns that file so it will overwrite any changes you make. The solution is setting/changing the DNS servers for a 'service' (connman speak for a connection) through connmanctl. I can't quote the syntax needed off the top of my head but there are man pages and Google for that kind of thing.
cp /storage/.config/system.d/wireguard.service.sample /storage/.config/system.d/wireguard.service^ then edit the wireguard.service file to call the connman service, and the tunnel is auto-started at startup.
Can we use installtointernal or only run off SD card
There are too many issues that arise from install2internal scripts so I have no plans to support it. That said:
Once I extract the FIP sources for Minix U1 and port the board to mainline u-boot it will be possible to boot modern u-boot from SD card and run the OS completely from eMMC. It is not possible to install modern u-boot and the OS to eMMC at the same time (as with vendor u-boot) as U1 is a GXBB device and GXBB needs to boot from the first sector of eMMC (so installing u-boot breaks partitioning .. and creating partitions breaks u-boot). The first stage boot from SD is a workaround, but it works and is much cleaner than the custom partition scheme that vendor u-boot implements. Minix U9-H boxes will be able to run fully from eMMC as GXL/GXM support an alternative offset for the magic boot header which allows partitioning to reside in first sector as normal. Until I get around to extracting the FIPs and doing u-boot work, the box must boot from an SD card. The performance difference is not so much.
Maybe the developer who is a member of Lakka simply lost interest in LE.
He's still actively working on Lakka which is still actively based on LE, but there are 1001 things that need a maintainers attentions and only so many free hours in a week for fiddling with hobby code.
My biggest gripe with RPi4 is a lack of hardware VC-1 decoding which no release of LE is able to fix. I've seen people claim it's a niche format which it is except it's standard for Blu-ray movies and is actually quite common especially among early releases. I wonder if software playback without framedrops is feasible with CPU overclock.
VC1 plays fine with software decoding which is why the Pi Foundation designers haven't bothered adding an IP block in hardware for it since the original RPi and RPi2 boards (which had weaker CPUs and needed it). It's the same for MPEG4 and a bunch of other codecs.
Out of curiosity what kind of optimization are we talking about? Decoding stuff in kernel?
RPi0/1/2/3 have no hardware decode capability for HEVC but this emerged as a more popular codec. The Pi devs used compute capabilities on the GPU (not the ARM CPU) to assist the software decoding process. It adds just-enough compute headroom on RPi3/3B/3B+ to handle lower-bitrate 1080p, as used with streaming services like Amazon/Netflix. It works, but there are no public APIs to handle this kind of thing in FFMpeg so it requires a bunch of proprietary code. That code and the optimisation tricks it contains depends heavily on the workflow of the video output pipeline; which is the bit that has been completely reinvented with the move to GBM/V4L2.
Hey that's a nice setup you have there. Considering that typical 4K HDR content is encoded with 10 bit color depth and that current LE release supports only 8 bits and trims the extra bits, have you experienced any trouble with that?
None. Current 8-bit output works fine and the majority of users won't be able to tell the difference once 10/12-bit output is supported (it is being worked on).
