NFS not playing videos since libnfs update

    Hi,

    I'm having an issue with playback (blank screen and no audio) from my DNS-323 NAS using NFS on a RPi5.

    I've tried the following latest le13 nightly builds:

    1) LibreELEC-RPi5.aarch64-13.0-nightly-20260808-7e66d59
    2) LibreELEC-RPi5.aarch64-13.0-nightly-20260810-393623d
    3) LibreELEC-RPi5.aarch64-13.0-nightly-20260810-46d0580
    4) LibreELEC-RPi5.aarch64-13.0-nightly-20260816-9a6f9e3

    1) plays as previous builds but there is a problem with dhcp versus manual ip setting *
    2) will not play
    3) will not play + when updated (copied file to the update folder) some settings reset (regional, whitelist etc.)
    4) will not play

    * this is a strange one - I have 2 drives in my NAS but one of them reports a network error when I have a manual ip address but works when I set a dhcp ip address. The other drive works with both dhcp and manual ip setting.

    wrt my NFS playback issue, this seems to coincide with the libnfs: update to 7.0.0 between builds 1) and 2).

    I accept that my NAS is very old (I have had it for over 15 years) but are there any settings I can change to make it compatible with the libnfs update?

    I use the first build you mention (as the last build from Friday I tried made libreelec unusable) and no issues at all with playback from the nas with nfs.


    I assume as the later builds cause issues for me too (I usually only update the nightly once a week) it might be a build related problem.

    I thought it had something to do with ffmpg, but the network might be plausible too, as when trying to copy files from the nas to the internal drive it indefenitly hangs at 100%.

    I appreciate all your responses - it's "good" to see I'm not the only one with the issue.

    plingplong I used the systemd mount method a few years ago when the internal NFS method wasn't working for me but I have, up to now, had success with it since then and would have to change my library paths again if I were to move back to systemd. If I find the time I'll do a test with the mount method but I would hope that since a few others were having the same issue then the developers may have a look into it?

    Wolfpig I too thought it was something to do with moving ffmpeg from 8.x to 9.0 but a ffmpeg 9.0 build works fine from a local drive.

    My biggest issue is that once I downgrade to the 08 nightly, I lose my skin, and VPN addon gets hosed and doesn't work. But I can play all my media. lol.

    I can then upgrade to the latest nightly, my skin comes back, OpenVPN works automatically, but no media plays.

    Hopefully an upgraded nightly soon will fix the media issue whatever it may be, even if it isn't libnfs. I had no idea what caused it. But as stated, glad I am not the only one with the issue.

    You can clone (cp -R) the contents of /storage/.kodi to /storage/.kodi-working and then systemctl stop kodi and swap .kodi folders around before systemctl start kodi as required for testing and reverting to a working state.

    Also please share a Kodi debug log using pastekodi from a release that demonstrates the problem. Share the URL generated here.

    chewitt

    Tried the last current build and the problem that no network connection exists...or temporarily does not exist.

    I do not know if this log will be helpful at all, as the uploading of logs does not work after the problem gets replicated by starting video files.

    No idea why/how that got created...but as i have to wipe the whole install to downgrade, a persistent log which might is stored on disc is not that easy to get either (or would it be possible to get them when the drive is connected by usb on a pc?)

    Build: 20260821-27ce188.img.gz (sha256)

    Pi5 4GB

    https://paste.libreelec.tv/overstayed-angelena.log


    If this post should better be made in the bug report section i will repost that there with reference to this thread.

    I was originally asking because I hit an issue with https://github.com/xbmc/xbmc/pull/29006 and (misreading the post on a phone) wondered if it was the same thing occurring - despite the 'Fix SMB' title the issue is a general networking issue and has nothing to do with SMB. Having re-read the description in a normal browser you're accessing the share in some form so the issue must be something different.

    NB: You can enable persistent debug logging in the settings add-on, then e.g. journalctl -b 1 --no-pager on the CLI should show the previous boot.