Run getedid create from the console with HDMI connected and the kernel will always see the TV as connected:
https://wiki.libreelec.tv/configuration/edid
You can also hard-disable the internal screen:
If the issue is something deeper in how the laptop hardware or firmware works, there is nothing we can do. We don't fix laptop firmware 
thomaz https://github.com/tvheadend/tvheadend/pull/2233 and changes should be in the .13 addon in our repo along with some dark-mode theme changes that I pushed last week. Some cleanup might be needed https://github.com/tvheadend/tvheadend/pull/2247 but the scan should complete now.
"User error: please replace user" 
Are you running the latest nightly?
config SND_ALOOP
tristate "Generic loopback driver (PCM)"
select SND_PCM
select SND_TIMER
help
Say 'Y' or 'M' to include support for the PCM loopback device.
This module returns played samples back to the user space using
the standard ALSA PCM device. The devices are routed 0->1 and
1->0, where first number is the playback PCM device and second
number is the capture device. Module creates two PCM devices and
configured number of substreams (see the pcm_substreams module
parameter).
The loopback device allows time synchronization with an external
timing source using the time shift universal control (+-20%
of system time).
To compile this driver as a module, choose M here: the module
will be called snd-aloop.No mention of SND_DRIVERS there ^ so looks like a kernel bug to report and submit a fix for
Honestly no idea and I'm neck-deep in debugging something so not going to spend time looking.
I bumped Kodi four days ago: https://github.com/LibreELEC/Libr…94747d2db405f63
So update to the latest nightly and it should be there.
If you have a working default image building, edit projects/RPi/devices/RPi4/linux/linux.aarch64.conf to enable the module then rebuild the image and it will rebuild the kernel and update the image.
At least that's the theory. It doesn't work for me on an Amlogic image with linux-7.3-rc2 kernel either, and diff comparing the edited conf and .config file from the kernel build folder shows the kernel has unset CONFIG_SND_ALOOP=m when processing the config; hence nothing gets built.
I will task Claude to investigate the problem once I take a break from some other debugging. I suspect some kind of upstream kernel issue and not something on our side.
I would have to rename them like 'Movie.Year.3D.SBS.mkv' – it seems that the letter 'F' is preventing the 3D recognition.
First world problems
echo "127.0.0.1 update.libreelec.tv releases.libreelec.tv" >> /storage/.config/hosts.conf
rebootRun that ^ over SSH
The fix will be in nightlies within 24h of this being merged: https://github.com/LibreELEC/LibreELEC.tv/pull/11756
You'll need to ask questions on the design intent in the Kodi forum; the author CrystalP is active there.
I noticed in the nightly builds that output for AMD radeon has shifted from YUV to RGB. Are we able to change that back? or at least offer a setting to switch?
AMD/Intel/nVidia cards *should* output in their native RGB format, and this is not a problem as long as the correct conversions are used; which are all broadcast standards. The change is that Kodi now implements and handles colour things correctly instead of not-handling them at all resulting in wrong output.
Make sure you have the GUI in expert mode.
Any clue what's causing this ?
Linux 5.15+ removed support for NTLM: https://git.kernel.org/pub/scm/linux/…782eb68f61a179c
There was some discussion about reverting the change but Linus rejected the idea https://lore.kernel.org/all/CAHk-=wjSB…mail.gmail.com/ and a simple git revert no longer works due to surrounding code change in the kernel.
Some workarounds are mentioned in https://bugzilla.kernel.org/show_bug.cgi?id=216682; AFPS support via FUSE is probably the right direction to move in. The original AFPS project looks to be quite dead but https://github.com/Netatalk/netatalk-client seems to be current and might be something we can package into an installable add-on similar to NTFS-3G.
I still have a TimeCapsule in a box somewhere, but I'm travelling and it will be a ~week before I can investigate further.
It's best to allow a week between iterations of kernel patches unless it's a final 'one last thing..' respin. Maintainers have crazy busy inboxes and work up them in date/time order so it's annoying to spend time reviewing something only to discover there are another three iterations of the same thing on the same day that need to be reviewed, with only minor adjustments in each. Allow time for people to send feedback, then send one next version that incorporates all that feedback. Also, when replying to messages always reply to the comments inline and never top-post as this loses context/conversation threading. The maintainers on the Amlogic list are pretty relaxed folks about such offences, but others can get rather irate about it. The same comments apply to u-boot and most upstream projects where the reviewer/maintainers are also kernel people.
That said, most people (self included) learn what's acceptable on kernel lists though trial and error, so annoying a few devs and being told off is just a normal rite of passage
Your options are ViwX, ViwX, or ViwX .. so best to warm up to the idea of using it.
If you implemented cache fiddling on the current RPi4 setup; remove it and you'll likely discover things improve, esp. with LE13 images. Why? because there is a sizeable chasm between how most users think media streams and caching work, and how it actually works, which results in people with utterly moronic cache configurations. Unless your network is broken (in which case the solution is always to fix the network) there is no need for anything beyond Kodi defaults, no matter what some outdated reddit or Kodi forum thread armchair pundit claims or recommends. K22 has changed things quite a bit.
RPi5 is a noticeable update on RPi4. Generic PC stuff is a little faster again. There is no performance difference between 4/8/16 GB RAM in terms of GUI and playback because 2GB is enough for 4K and the GPU and Kodi desktop resolution (and key-repeat/scroll speed of the remote device) dictate how fluid things feel, not RAM size. These days 16GB seems to be the minimum DIMM size that you can so not sure anything smaller is even possible. The difference between DDR4 and DDR5 is likely irrelevant for LE use.
I have an RPi5 booting from an NVME drive (family daily-driver) and an Intel N150 box with eMMC storage (x86_64 dev work) and while the Intel box is technically a lot faster, the real-world difference is more marginal.
