Worst case .. stop Kodi and rename /storage/.kodi to /storage/.kodi-old and then restart. You now have a clean install. You can stop Kodi and move back things you need (sources, thumbs, DB files, etc.) but redo add-ons .. without tubed.
FWIW I have both YouTube and Tubed installed and never see any problems with either of them, so it sounds like something got messed up.
The only time I've seen long delays before playback, users have fiddled with cache settings to avoid buffering after following some nonsense advice and set an insanely huge cache size; which needs to populate before playback can start.
remove the Options= ?
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.
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.
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.
Browsers are an x86_64 thing. Maybe one day Kodi adds this capability - it's been worked on but the code never made it beyond prototyping and if work ever resumes it will require the newer GBM/V4L2 graphics stack to run on.
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.
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.