This could potentially mean an additional 300,000 users
Nah, we know our userbase. At least 99.9999% of it has no clue about custom TLS certs. In a good year we might get 30 more.
Posts by chewitt
-
-
I'm running 12.0.2 on an RPI4B
Please install the latest LE13 nightly on a spare SD card and see if the same issue still exists there. If yes, I'd like to see a PCAP of the DHCP request.
-
How do I get webgrab++ for LibreELEC?
Install Docker. Install the LinuxServer Docker add-on repo. It should be in there. If not, you can just pull their container direct from Docker Hub: https://hub.docker.com/r/linuxserver/webgrabplus
In the past there was an dedicated add-on in the LE repo, but people come/go from the project over time and it went unmaintained, and was eventually marked broken and removed from our repo back in 2019.
-
RAM isn’t the issue. VC1 files will be software decided so it’s about CPU. Here the RPi5 wins, but I’m not sure what the limits or expectations are for RPi4 with that codec.
popcornmix any opinions? -
Nah. If renaming a file to “cacert.pem” is too complicated for you, you shouldn’t be messing with certificates in the first place.
-
The “ip a” command won’t survive a reboot but it’s trivial to put into an autostart.sh script or systemd service that’s executed on each boot.
Have you tested whether it’s something simple like the router not matching the MAC due to uppercase or lowercase letters. Some routers are crap like that. What’s logged on the router?
-
Problem is,when DHCP is selected, it always defaults to 192.168.1.126
The output of ip a that you shared disagrees with that statement as it clearly shows eth0 is assigned 192.168.1.5/24 as configured in the router. What makes you think it has the address 192.168.1.126 ?
The lifetime values can be manually changed with:
Codeip a change <ip> dev eth0 valid_lft <value> preferred_lft <value> -
I've got an AI-TAK TV box RK322X-box running Android version 6.0.1
You should ask the question in an Android support forum. We don't support Android.
-
I've never used them personally, but flatpak replaced the official Kodi apt repo so perhaps look in that direction.
-
Yes, I have tried with other nightlies and is exactly the same.
Not LE nightlies, Kodi (on Debian/RaspiOS) nightlies.
-
Is there anything i can do to help determine if it is LE specific?
Run a recent Kodi nightly version on RaspberryPi OS on a spare SD card with the same skin. If you see the same issue (which you should) it's nothing to do with LE.
-
Looks like a skin thing. Even if it’s not and it’s something related to UI rendering on RPi, it’s still best addressed by Kodi who implements the shaders, or skin devs; it’s very unlikely to be LE specific.
-
Vero 4K+ is an S905D (GXL) board with GBit Ethernet .. it's not going to be perfect (as per the current state of hardware decoding in the upstream kernel) but should be usable with un-exotic media. There's nothing special about the 4K+ hardware.
-
Do we have to guess what hardware you are using? .. esp. the GPU type/model.
-
So if it set only a few second to wait, when expired, the LE will continue to boot even without network connection.
That's normally true, but when you enable the wireguard.service you add hard "after ntp" and "before kodi" dependencies to the boot sequence and because there is no valid network connection the ntp check never completes and thus the Kodi service which makes the wait-for-network check is never reached.
The only way I think you can workaround this, is to stop/disable/mask the embedded Kodi startup systemd service (which runs an embedded shell script) and replace it with a modified service and script that's enabled/run from from somewhere on /storage; with the modified script containing logic to start wireguard before Kodi only when a valid network connection has been established. You basically need to extend the wait-for-network logic to include wireguard.
-
You're over-thinking the problem. Trying to write the .img to disk again is only going to cause problems because the .img format we use for releases is designed only for overwriting an entire disk. Make a one-time manual install of the partitions and filesystems, and then 'update' to newer versions as required. An update replaces the entire embedded portion of the OS (via KERNEL/SYSTEM) and if you need to wipe the Kodi config all you need to do is stop Kodi and rename /storage/.kodi to /storage/.kodi-old and reboot. On restart you have a completely clean Kodi config. Config items also exist in /storage/.config or /storage/.cache, but it's unlikely that you need to touch anything there.
-
I downloaded the files from that GitHub repo:
- Centre starts with FL, FR, but then plays FC.
- Quad plays FL, seems to hiccup slightly with FR, then plays RL and RR.
- Stereo plays fine.
- Surround50/50/61/71 all play fine on main channels, there's a quiet moment which I assume is LFE.
I'm using an LE13 nightly image: https://chewitt.libreelec.tv/testing/LibreE…h64-12.80.2.tar
-
I have fuzzy recall that the setting is fixed/working in the LE13 nightlies, so perhaps put one on a spare SD card and see (first).
There is no way to configure networking from the SD card.
