ConnMan manages /etc/resolv.conf and assumes ownership so manual edits can be overwritten at any time. If the host has a static IP assignment it's probably easiest to add an entry in /storage/.config/hosts.conf and reboot.
Posts by chewitt
-
-
I didn't see anything banned, but it's not a debug log and there's nothing obvious in the log .. hence 'nope' answer.
-
can you describe what happened ?
Nope.
-
Kodi allows you to fiddle with the type of input stream that uses buffering (it differentiates between online and several different types of local sources), the size of the buffer, the buffer fill-rate, and (separately) the SMB/NFS read-chunk size. Note that since K21 the buffer settings have all moved into the GUI so config in advancedsettings.xml will be correctly ignored.
Users generally (and wrongly) believe that "bigger buffer is better" but when you have insufficient bandwidth the buffer always drains to zero and then you stall playback until the buffer is full again and can resume. Having a larger buffer or a slow fill rate means you will wait for longer before playback resumes. Fast fill rates also imply the availability of faster/higher bandwidth. In practically all scenarios, smaller buffers and moderate fill rates (small changes on defaults, not radical ones) give best results.
NB: Cache tweaking is never a cure for "insufficient bandwidth" and you will probably spend more man-hours of effort trying to find a combination of settings that is best (or least-worst) than it will take to fix the real problem: the NIC is negotiating 100-BaseT not 1000-BaseT. Check the router, switches, cables, ports, etc.
-
RPi5 2GB is our minimum recommendation. The 4GB/8GB board variants aren't necessary unless you want to run other services in the background via Docker or add-ons.
-
RK3588S2 is merged to mainline kernel 6.3.
Current state for RK3588 upstreaming is tracked here: https://gitlab.collabora.com/hardware-enabl…nline-status.md - the Mali GPU has been supported since Linux 6.10 but LE images also need HDMI support (1080p is merged/queued for Linux 6.13) and once 4K is working we'll need HEVC/VP9 media codecs working (WIP).
It has platinum support in Armbian.
Feel free to use Armbian then. It's a project that undertakes commercial work to support devices; meaning they will tolerate vendor kernels with horrible code and patching to make something work. Their primary user audience is developers of industrial products who have use-cases that don't need media features, and hobbyists needing a desktop environment who again aren't so needing of the media capabilites. I have no knowledge of the current state of their RK3588 support .. but since most of the media stuff is simply not upstream yet, they are either managing a load of WIP patches and/or the media features aren't in great shape.
RPi5 proves that a fast board can handle software-decoding everything at 1080p so a little patching on Linux 6.12 can probably result in a usable but basic LE image, but I doubt anyone on staff or community will take serious interest in trying to assemble images until HDMI 4K support lands. So the realistic target will be after LE13 ships (2025/Q1).
If you want a functionally complete and well supported SBC for LE use, it's an RPi5. The 2GB board is enough for normal use. You only might need more RAM if you want to run Docker containers with other services in the background. The spec on paper isn't as impressive as the Rockchip board, but it shipped with functional support on day1 of release vs. RK3588 is now 3-years on from it's release and the board only just got upstream HDMI support. Hardware specs are nothing without supporting software
-
If it's a small library and you're planning to move content over from USB drive to the SSD it's probably easiest to move the content over and rescrape everything from the new location.
If it's a larger library and/you care about the watched status, the following /storage/.kodi/userdata content can be copied over:
- DB files
- sources.xml
- passwords.xml
- addon_data
- thumbnails
As the original /var/media/USBDRIVE path will have changed to /storage/videos/something you will need to use path substitution to map old paths to new ones, see https://kodi.wiki/view/Path_substitution
NB: No add-ons can be copied over as LE9 uses Python2 and we switched to Python3 since then.
-
Interesting. I suspect the solution is in the AVR config options then. Perhaps the port is tagged for some specific output/purpose and isn't doing the usual "mirror upstream capabilities" that normally happens.
-
Two related changes that allow local console login:
systemd: support local console login · chewitt/LibreELEC.tv@12c63b7
I've used them when repurposing LE to create a minimal OS image for running Docker containers.
-
The second issue is that my internal wifi is working, but I can't get my newer USB WiFi adaptor to be recognised (newer WiFi6 compatible device). It is a Simplecom NW812 adaptor which appears to be using a Realtek 8832BU chipset.
RTL8832BU is not supported by the upstream kernel at the moment so you would need to self-build an LE image that includes the vendor drivers - we have long refused to add more of them because they're a pain in the rear to maintain over time. I can see a version of the driver here: https://github.com/lwfinger/rtl8852bu although the owner of that repo passed away recently so it's not being maintained and might need minor patches for the latest kernels. Self-build instructions are here: https://wiki.libreelec.tv/development/build-basics and you can crib the buildsystem package format from what we removed in https://github.com/LibreELEC/LibreELEC.tv/pull/9394 - normally all you need to do is change the package name and URL (and then hope the driver builds without needing patches).
If that sounds like rocket science and a change of WiFi card sounds easier https://github.com/morrownr/USB-WiFi has some good and current/up-to-date info on current state of Linux USB WiFi devices.
-
It should work.
-
HarryH Those issues are irrelevant to data copied to the LE device (LE hosts Samba server) which will not us the in-kernel SMB client drivers.
-
Install latest nightly. Then run "echo options brcmfmac feature_disable=0x400000 > brcmfmac.conf" over SSH, reboot and test.
-
Just in this case, it just creates a little obstacle, not really preventing piracy tools on LE.
Little obstacles and project stance are important from a legal perspective if not a practical one.
-
I know that gpu memory, cache, buffer etc. can be added or managed. Or it's really useless ?
GPU memory is fixed at boot time and we already optimised consumption. Kernel caching has a simple rule: "if you understand the kernel documentation, do what you like, else leave alone" and since 99.99% of users will not understand kernel memory architecture it's best left alone. On the Kodi side users like to tweak cache/buffers settings thus undoing thousands of man-hours of effort to optimise the default settings with a ham-fisted bodge from a forum post where a user with a different use-case and no great clue about the underlying mechanisms said it made things better. As a broad rule cache settting changes will fix one thing and cause three more things. So feel free to go nuts .. do the reading (lots of kernel docs, RPi docs, Kodi docs are out there) but when it all makes no different or causes issues - revert back to the defaults and marvel at how things just work again.
-
I don't know what button you're talking about, but you described Kodi as being stuck (sound like non-functional), and when Kodi is hung it probably doesn't process button presses
-
Yes, the #1 use of entware on *ELEC distros is installing piracy tools. We work closely with Team Kodi and take a similarly firm stance on that kind of thing. It's our distro and our choice. If you disagree .. feel free to fork our codebase and run a distro. CE isn't the first fork of our codebase and won't be the last. Forks are an essential part of our ecosystem. We like forks
If you want entware on LE you need to self-build an image with /opt added. Have a look at packages/sysutils/systemd/tmpfiles.d/z_01_openelec.conf for some prior art on adding directories.
Build instructions https://wiki.libreelec.tv/development/build-basics
-
As Wireguard seems to be the way to go in the future, it would be very nice to see it implemented directly into LibreElec
You mean like this? (4.5 years ago) https://github.com/LibreELEC/LibreELEC.tv/pull/4139
