Run "getedid create" and then reboot. The getedid script will capture the EDID data to a file which is then used to fake the connection to the TV so the Pi thinks it's connected at startup even when it's not.
Posts by chewitt
-
-
I always like to ask the question: does it work good-enough for your use-case? .. because users frequently obsess over how to force a device to use 5GHz "because it's faster" but the kernel 80211 framework is written to figure out which frequency band gives the better signal and use it, so while 5GHz theoretically is faster it's also more susceptible to poor signal problems, while "lower speed" 2.4GHz with a better signal may give you higher throughput. It's also important to focus on "fast enough" vs. "max theoretical speed" because if it *is* fast enough, it's fast enough. Only "not fast enough" is an actual problem. NB: Regdom can be set from within the LE settings add-on these days, so no need to use modprobe options files.
-
H264 10-bit is not a broadcast standard so almost no SoCs/GPUs support hardware decoded playback and software decoded playback is VERY taxing on the CPU. Your clip is also high (5.1) profile with 16-reference frames. Historically we see most animé fans using an Intel NUC with a fast Core i7 chip to handle such media - it also cannot hardware decode but the CPU has enough oomph. What you're describing is exactly what i'd expect from any ARM SoC including an RPi4. The only solution for playback an RPi4 would be re-encoding the file to 8-bit H264 or 10-bit HEVC, both of which can be hardware decoded.
-
If it still has an internet connection you can pastebin system logs from the settings add-on. Share the URL displayed on-screen and we can see if there's any clues to what's going on.
-
-
Please provide a full debug log.How to post a log (wiki)1. Enable debugging in Settings>System Settings>Logging2. Restart Kodi3. Replicate the problem4. Generate a log URL (do not post/upload logs to the forum)
use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link -
Clean reboot and demonstrate the problem, and the log will be under 512k.
-
I asked Pi devs. It's hard to find AV1 media (not 4K) but last time they did somtehing with basic clips RPi4 was handling 720p HD fine and 1080p was borderline but there have been optimisations in AV1 code since which might improve it. RPi3 didn't cope with 720p.
I've never seen an RPi400 but it's basically a repackaged RPi4 4GB and project stats show RPi4 4GB to be our 2nd most popular device now. I use an 8GB as a daily driver; the RAM size isn't important, over 2GB is fine. Extra RAM is only useful if you plan to run other apps/containers under Docker.
-
-
Unless you disabled CEC in Kodi settings .. we should show up as a device too. It does sometimes depend on which HDMI port is being used on the TV end.
-
*FULL* debug log. If you snip the early stuff off we cannot see certain config bits that are good to know.
-
LE/Kodi already supports fallback to software decode for unsupported [in hardware] codecs - it's how we play HEVC on RPi3 today. I have no expectations performance-wise that AV1 would be any different to HEVC on RPi3. `RPi4 is also missing hardware support but has considerably more ARM grunt so will probably fare better, I haven't personally tested but suspect it can handle lower-bitrate AV1 (1080p, forget about 4K) which reduces the likelihood of anyone investing time/effort in software optimisation. I'm sure Pi Foundation will consider adding an IP block to their next silicon generation if it becomes a mainstream thing in the broadcast world.
-
Code
WP2:~ # cat /etc/resolv.conf # Generated by Connection Manager nameserver 172.16.20.1 WP2:~ # ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 26 Aug 10 16:34 /etc/resolv.conf -> /run/libreelec/resolv.conf
^ The file is present for me, and contains a nameserver obtained from DHCP, the file is managed by ConnMan (the connection manager) and is linked at runtime to /run which is a writeable volatile area of the filesystem. There is no need for OpenVPN to update this file (at least with conventional client-server VPN use-cases) so we dropped OpenVPN support from ConnMan (connman-vpnd) ages ago.
-
The lightning bolt is an overlay from the RPi firmware to indicate inadequate power supply.
-
It's not impossible, but you will need to self-build an LE image with different kernel config options and options/changes to the connman package to add support for IPSec VPN types.
-
RPi3 hardware deinterlace is being actively worked upon and public testing of code should happen soon. Support for 3D is something that can probably be done and one of the Pi Devs has a 3D TV so while it's niche and not a priority for the Foundation, personal interest will probably make it happen eventually. The advantage these "missing" features have is, they also benefit RPi4 support. Software HEVC optimisation for RPi3 is a little different and IMHO unlikely to be reimplemented. One objective of the new video stack is to get everything upstream to make RPi support consistent and better in all distros: previous HEVC support only ever worked in LE and OSMC because we were prepared to add 50,000 LOC patches that normal distros with mature package/patching policies refused. HEVC is probably not technically impossible to do in the new video pipeline, but it would (again) need large unorthodox changes that would never be accepted upstream, and the changes need a ground-up rewrite not adaptation of the previous approach so it's a considerable effort. Meanwhile RPi4 has native hardware decode that works nicely, and while the code is not all upstream yet, ffmpeg is the main missing bit and that effort will start sooner than later. Forcing users to upgrade to profit the Foundation has never been an objective with any of the Pi developers, but upgrading to an RPi4 is the simple and obvious option for anyone who needs HEVC support (and you get 4K, HDR, HBR audio included too).
Matrix is K19/LE10 and there is a release thread. K20 is in a pre-Alpha state so there is no LE11 thread at this time.
-
-
VNC can work under GBM/V4L2 (there is prototype code) but it currently requires full copies of frames to be made which is compute expensive and results in high-CPU load so the FPS rate need to be deliberately hobbled to keep things sensible. For people who really MUST use VNC to remote navigate a box it sort of works (with dial-up modem framerates) but it's not a means of watching movies. I don't think anything will be made public until a more efficient way to output video is figured out.