Most add-ons are not authored by LE staff and 'legal' media content/streaming ones are generally supported via threads in the Kodi forum where the add-on creators hang out. If you want us to help, you'll need to divulge clues like the type of hardware used, image version, specific add-on details (no idea what "esa" is) and likely provide some logs (read the wiki).
Otherwise it's a bit like saying "my car doesn't work, it's a red one, what's wrong?" .. 
Dec 29 04:17:50 LibreELEC kernel: bluetooth hci0: Direct firmware load for qca/rampatch_usb_00190200.bin failed with error -2
Dec 29 04:17:50 LibreELEC kernel: Bluetooth: hci0: failed to request rampatch file: qca/rampatch_usb_00190200.bin (-2)I've pushed an updated version of the image with that ^ file added. Hopefully that's the only one. In case it's not, chase down files from https://git.kernel.org/pub/scm/linux/…re.git/tree/qca and let me know what others are needed so I can add them to the pick list.
I thought if I copied them to my local LE build 'sources' folder the build would work, but the build process actually ignores the existing file and attempts to d/l anyway
You can fake/do that *if* you add the .url and .sha256 files alongside the source file. If you only add the source file, the buildsystem sees it as an incomplete package and reattempts download.
See if this LE13 image works? https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz
If not working, run journalctl | paste and share the resulting URL so I can see the system log for clues.
swever the images include the latest rtw88/rtw8821a_fw.bin firmware from the upstream linux-firmware repo and nothing has changed with that in the last few months. If you have files in /storage/.config/firmware/rtw88 these override the lastest upstream files so I would suggest removing them and using upstream firmware. If that doesn't fix something; clean boot then "journalctl | paste" and share the log URL so we can look for error messages etc.
The Generic image is not currently built with CONFIG_ATH12K enabled hence adding firmware doesn't achieve anything. I'll share an LE13 test image later in the day that includes the missing module and firmware. If you can confirm that works I'll send the changes upstream to our main repo.
This is unlikely to be an LE issue as we're not doing anything more than packaging Tvheadend. It is possible that differences in the two versions are due to changes in Tvheadend itself. It's also possible that the issue resides in the browser.
I'm wondering if this is the same as https://tvheadend.org/d/9323-recordings-dont-play-anymore/8 ?
NB: Although there are quite a few Tvheadend users around here the best place to report and debug Tvheadend problems is normally the Tvheadend forum.
flydt Please reply in this forum thread. If you continue to "report" the post and reply that way, a) nobody except admins can see the reply/report, b) you'll be receiving a temporary ban for annoying the admins with unjustified reports to review.
I confirmed with a laptop that the display does support 1280x720, so version 12 works but only detects a subset of the resolutions.
popcornmix any ideas what the difference might be?
Images in my test share are bumped to Linux 6.19-rc2. No functional changes are expected although I suspect some of the in-flight 4K60 patches have matured as test files in [email protected] and 4K@60 seem to be more stable. I'm hoping the new year brings upstream merges so the number of patches required reduces and become less of a juggling act.
Thread moved to off-topic because we have no secret stash of Android ROM images for 12+ years old clone-box Amlogic hardware that predates the existence of LibreELEC.
The gotcha with SMB is that the default connect version in smbclient is SMBv2, and while the client can/will upgrade to better SMBv3 on successful connection it has no logic to attempt a new connection with SMBv1 on an unsuccessful SMBv2 attempt; the connection attempt simply fails. This was an intentional move (some 20 years ago) to herd people away from insecure SMBv1 and while there is logic to how it works, the behaviour can catch people out sometimes.
My kids have the habit of pressing the big 'play/pause' button on the remote instead of using the small 'stop' button. This means Kodi is often left in a playback state so the display remains in HDR mode (albeit with the 'black' screensaver active) until hours later when I spot it and finally press 'stop' on the remote to end playback. Perhaps something similar is happening..
NB: That should have nothing to do with PM4K issues; that's something else, and no idea what without seeing logs of some kind.
You should only need to enable Samba with min SMBv2, max SMBv3 (the default) and with auto-sharing of USB drives turned on (the default). Modern Windows require SMB authentication so that needs to be on (not enabled by default).
If "Can play media from local Windows 11, Kodi app usb new volume." means the Kodi SMB client on a Windows Kodi install can play media from the LE Samba shares? .. the shares are working. The Kodi SMB client is different from the OS client (explorer, etc.).
Have you tried accessing via \\192.168.2.1 (or whatever the IP is) instead of \\LIBREELEC?
Option B .. use an SFTP client and transfer files over SSH instead.
Does "systemctl status raid5.service" show any errors from the commands when they are run? - Are there any errors in the systemd journal or showing in dmesg? I'm wondering whether some sleep delays might be required space out commands? - filesystem tasks can need time to complete/settle before you run the next command; systemd ExecStart sequences need the same considerations as putting commands in a bash script.
I'm wondering if it's possible to set this setting in LibreELEC, and if so, how.
Not without compiling a custom image that swaps iwd for wpa_supplicant, as we switched to iwd some time ago. You'd also need to add or expose a method for runtime pre-configuring the conf.
Latest release is 0.7.0. Why isn't this upgraded?
On which LE version?
