Most likely you have a VM running on the Windows machine and its address is selected. Use nmblookup BEJHAN-PC on the RPI to verify.
If yes use smb://[email protected]/
See pvr.mediaportal - working in LE 9.26, not working in LE 10.0
Most likely you have a VM running on the Windows machine and its address is selected. Use nmblookup BEJHAN-PC on the RPI to verify.
If yes use smb://[email protected]/
See pvr.mediaportal - working in LE 9.26, not working in LE 10.0
Most likely you have to use irserver64 on a 64 bit system.
Likely the behavior was changed in kodi with PR19040 using nmblookup via CDNSNameCache::Lookup().
To my surprise Kodi is preferring nmblookup addresses over NSS and using the last listed line.
why does LE 9.26 work in this environment.
Is there a difference in nmblookup output (because of older version)?
There is another report resolving a wrong address from SMB share (without mediaportal): SMB broken in nightlies RPI4
Samba is doing it's own name resolution and in the last post OP found the address listed in nmblookup. Please try nmblookup NCC and nmblookup -A 172.20.208.1.
BTW: nslookup is only querying DNS servers while the system library name resolution is using the methods defined in /etc/nsswitch.conf. For hosts these are usually files (->/etc/hosts). MDNS and DNS. This can be queries with the getent ahosts ... command mentioned.
Here is another log from LE 9.95 (Allwinner H6) when pvr.mediaportal is configured to use RTSP instead of SMB:
RTSP failing too makes the error even more mysterious to me - maybe caused by caching of addresses.
Comparing LE 9.2.6 with 9.95 does not help, almost every part was upgraded.
MS-Discovery is not available for Linux and SMB1 is disabled. Zeroconf/avahi MDNS seem to be more "agressive" in recent versions and resolving names directly.
Your smb://MY-Username:MY-Password@NCC address is resolved to smb://USERNAME:[email protected] - maybe matching a virtual machine on your Windows system.
Likely you get the same address with getent ahosts NCC in LE.
Use the IP address instead of the name.
To get smooth playback on Generic add PR19448 to kodi.
Have you already tried a nightly after 20210328 including kernel 5.10.26 with an additional AMD iommu.c fix?
Feedback overnight from the other user reporting the error “it disappeared on 5.11 for me.“
In such cases it is always worth to even try RC mainline or bleeding edge drm-next kernels.
There is a warning but I don't know if this is related:
Besides, why did you say it was your fault?
I had the impression the issue only reported foor recent kernels. But it exist in kernel 4.19 too and therefore in LE 9.2.6.
This is a RPI4 kernel issue: LE10 rpi4-4gb oom errors / USB3 disk writes trigger OOM reaper on Pi 4 · Issue #3210 · raspberrypi/linux · GitHub
Edit: My fault., the issue seems only be reported for recent kernels like in LE 9.95 - not in your 9.2.6
Edit 2: Does exist in kernel 4.19/LE 9.2.6 too.
Things happen. The fix missed 9.2.6. Testing LibreELEC-settings addon · Issue #4547 · LibreELEC/LibreELEC.tv · GitHub is the only possibility to have it in 9.2
There is already a 9.95.1 fix to start service addons after installation: Revert "kodi: service addon wrapper call fix" by HiassofT · Pull Request #5251 · LibreELEC/LibreELEC.tv · GitHub.
In the meantime disable and enable again the service from the addon settings.
In addition use an URL like https://gitlab.freedesktop.org/mesa/mesa/-/archive/master/mesa-<commit id>.tar.gz to get reproducible results.