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?
But that's exactly how I did it, .. O.K., my lines looked like this:
Your version executes connmanctl to run mount commands, which it cannot do, thus guaranteeing failure.
Have you connected a software RAID 5 to your LibreELEC distribution from sky42 and gotten it working?
No, because I use a Synology NAS in the network with a hardware RAID6 configuration 
[Unit]
Description=RAID5 Service
After=network-online.target nss-lookup.target time-sync.target
Wants=network-online.target nss-lookup.target time-sync.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/mdadm --assemble --force /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
ExecStart=/usr/bin/mkdir /media/RAID
ExecStart=/usr/bin/mount /dev/md0 /media/RAID
ExecStop=/usr/bin/umount /dev/md0
[Install]
WantedBy=multi-user.targetCreate as /storage/.config/system.d/raid5.service and then enable/start the systemd service. If you can run the same commands over SSH to mount the array the sky42 image contains all the software bits needed. If you cannot then it doesn't. NB: Check the actual path for mdadm in the image, I've assumed it's in /usr/bin.
The default password is defined in LibreELEC settings and is libreelec/libreelec not root/libreelec. Modern Windows OS versions will need to use authentication so you need to have auth on.
The only thing that comes to mind is SMB versions? .. i.e. old NAS was configured for SMBv1 which requires the Kodi SMB client on the RPi to be configured for min/max SMBv1 (else it connects at SMBv2 and cannot downgrade the connection to SMBv1) and new NAS has defaulted to SMBv2/3 thus prevening the Kodi SMB client trying to use min/max SMBv1 from being able to connect.
If that's not the right blind guess, as a minimum you'll need to divulge what protocol is used by Kodi.
Fcast reminded me of https://xkcd.com/927/ 
Use the wireguard systemd service as a template for something that runs after the network is up and before Kodi starts; change the systemctl command for whatever commands you need to mount the array. Add more ExecStart= lines as you need to run the commands in sequence. If you need more logic and error handling put the commands in a script in /storage/.config and then run the script from the systemd service.
I'd guess that's the performance issue that the pmdomain patch (we dropped) referred to. Was it enough to just add the right kernel options for the regulators to get things booting again or was the patch revert essential?