Posts by chewitt

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.

Quote from rmullen

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.

Quote from lyr7d1h

Latest release is 0.7.0. Why isn't this upgraded?

On which LE version?

Quote from Lordy

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.

Quote from Lordy

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.target

Create 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?

Casting features need to be implemented within Kodi not the underlying OS (LibreELEC)

rkman Saying "black screen" and then "rendering works fine" sounds contradictory so I'm guessing the Kodi home screen shows up eventually? so the screen is only blank during early boot?. If yes, this is prob. due to the kernel now supporting 4K output and in early boot a 4K mode the TV doesn't quite agree with is used. The workaround is to append video=HDMI-A-1:1920x1080M@60D to the kernel boot params in extlinux.conf so initial output is forced to 1080p instead. As a general rule you want to run Kodi at 1080p and only switch to 4K for playback anyway (see https://wiki.libreelec.tv/configuration/4k-hdr).

NB: If the board is booting from downstream Rockchip u-boot on SPI flash you can probably expect random behaviours. It's best to wipe SPI and allow mainline u-boot (2025.10) on the SD card or eMMC module (wherever LE is flashed) to be used instead.

ffmpeg 7.0 was updated to 8.0; the add-on repo version was already bumped and add-ons are already being built. The mpd add-on should update itself in the next 24h.

The existing config worked fine at one point but systemd is a continually evolving beast so perhaps something was improved and now needs additional config juju for things to work as before. If something needs fixing .. send a PR with a decent explanation of what is being changed and why, and it will be tested (over a range of build targets) and if good, merged.