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.
Posts by chewitt
-
-
Code
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).
-
Is there a time-schedule for the 10.0.1 Release? (with new Kodi and playback fix for corrupted recordings - RE: LE 10 Nightly unstable / Kodi crashing on RPi 4B)
No specific schedule, but soon-ish. There are some bugs we'd like to resolve first.
-
LE Settings = Samba Server, Kodi Settings = SMB Client. You need to set Kodi SMB client to min/max SMBv1 and if the SMB implementation is really ancient and rubbish you may also need the legacy security option setting.
-
Can we hope to improve the LE 10 for the odroid C2?
It should be quite usable for H264 things now (1080p, not 4K) and with the 41KHz/48KHz issue resolved I've re-enabled HDMI in the alsa-conf and passthrough works fine. I'm still trying to figure out why audio channels are mixed up with non-passthrough media, and the static noise bug is there as a nasty suprise when it happens. There's been some discussion on the linux-amlogic mailing list to "ask the audience" on that problem, but so far no eureka moment. No change to video - still neglected
-
Can some one guide me to detailed install instructions on how to get this to boot on my Minix U1. Ive tried Belana Etcher, Rufus placing the correct dtb image on card. Toothpick method and nothing. Can someone guide me to a solution. Thanks
Create an SD card from https://chewitt.libreelec.tv/testing/LibreE….0.1-box.img.gz then set the minix u1 dtb name to use in uEnv.ini (the filename is in the dtb folder). NB: You do not rename anything to dtb.img or move files to the root folder (unless you want to break boot). I'm not sure what state the U1 dtb is in right now - I did work before but it wasn't widely tested. Also note there are a few audio glitches to resolve still (in addition to all the video things).
-
Minor progress on a couple of things: One of the issues with the audio driver used with GXBB (S905) boards was figured out so there is no longer any need to force output rates to 41KHz to output 48KHz media. See: https://patchwork.kernel.org/project/linux-…googlemail.com/. This also leads to a major simplification for alsa configuration which we will send upstream. Sadly we still didn't figure out *that* static noise problem for GXBB/GXL/GXM devices yet, and this is what I regard as the minimum fix before some nightly images can resume. In the background I also have the full vendor sources and schematics for Minix Neo U1 (S905) and U9-H (S912) devices. I plan to extract and post the boot fips so that mainline u-boot support is possible. I can also validate the device-trees which have previously been created with user support (U9-H is upstream, U1 still wip).
-
Tethering changes default routes. It's hard to know whether that's an issue though .. I've never used Rasplex (which is a dead project these days) and the OE codebase it was forked from is also rather ancient now. Show logs of anything/everything and we might be able to figure out what the problem is.
-
Two things come to mind. First, LE has a local firewall that can be enabled. Second, the ports aren't mapped in the container configuration.
-
Google limits the number of searches per API key so the default key in the add-on is exhausted quickly. The workaround for this is creating your own 'app' as a Google developer and then configuring/using your own API key (with your own limits). This is probably what the YouTube video is instructing you on.
The buffering issues are something separate: Google has started throttling unofficial clients. Workarounds for this are still being figured out.
-
Code
cp /etc/connman/main.conf /storage/.config/connman_main.conf sed -i 's/PreferredTechnologies = ethernet,wifi,cellular/PreferredTechnologies = ethernet/g' /storage/.config/connman_main.conf reboot^ Removing wifi from PreferredTechnologies should ensure eth0 always has the default route (maybe .. not tested). You can then create a systemd service file to set defaults routes after the network is up and before Kodi starts.
-
I don;t know what IP is used for NPU in RK chips but in general NPU drivers are often a challenge to upstream due to NDAs and restrictions on the SDKs from the IP owners.
-
Just disable update checking in the browser.
-
It makes no functional difference whether you update from .tar or .img.gz files, but .tar is a little faster. I did make a mistake in the commands though, I did not recreate /storage/.update though I hope you spotted that as the next command was to cd into that dir before downloading the .tar tile. Please check the udpate file is in /storage/.update (note the . it is important) before rebooting to update.
-
The Kodi Plex add-on is a client with a sole purpose of playing media stored in a Plex server. If you want the media to be visible in the Plex client you need to add it to the media library in the Plex server. If you run a Plex server on the same HTPC host as Kodi (and the Plex client in Kodi) you can map media from local drives. If you run the Plex server somewhere else; you'll need to remotely mount the drives so that the remote Plex server host can see the media on them to add into the Plex server library. Kodi doesn't follow a rigid client/server model in the same sense; the GUI just provides access to media wherever you store it, and in your install that media is local which is easy.
It is not possible to change the behaviour of the Plex add-on without writing code to change the behaviour. As the current add-on is created by Plex staff the behaviour is intentional and I doubt changes to access local media would be welcome.
