How to check if this is a problem with samba or not:

In T9917#192351, @nazar wrote:

@ermo, if I understand you correctly, any change in binary-addons requires kodi full rebuild, and this was happening too often. Is that right impression?

So, for reference:

@TClark77: I took the liberty of retitling to 1.0.23 and add the correct link to upstream NEWS file (it was previously a copy-pasta from pidgin). =)

In T10005#189908, @Staudey wrote:

Possibly fixed by D12235 then

In D12305#207607, @JoshStrobl wrote:

Was the removal of libjpeg-turbo-devel intentional? If not, it can be added back, but as pkgconfig(libturbojpeg)

Add back accidentally deleted libturbojpeg.

There. Now things look (and work) like they should.

Add back pkgconfig(liblz4) to deps.

Turns out the removing pkgconfig(liblz4) was not a good idea. Adding it back in. Please hold off on landing it until I've updated the abi_* files.

Diff pushed per review.

Remove unnecessary deps.

Update per review.

Add newline at end of file.

Adjust release number.

In T9916#188406, @maikwoehl wrote:

Maybe it would be a good idea to add this approach to the Help Center. So anyone can search for "automount" on Solus and will find that approach.
I guess because Gnome and KDE have their own automount stuff for USB drives and SD cards, this is more for the advanced user?

If you're open to an alternative approach (= workaround), I've had success with configuring systemd automounts too. The trick seems to be to configure systemd to have an unlimited timeout for the units in question.

@joebonrichie If the problem is linking when using clang, then you can limit the amount of linker jobs by setting -DLLVM_PARALLEL_LINK_JOBS=1 and keep compiling with e.g. %ninja_build -j4 or w/e.

Out of nothing but curiosity, have you tested if smb:// URI access works on both guest/anonymous shares as well as user+password shares?

In D11025#182288, @aleksvor wrote:

Fix VLC getting stuck on close on X11.

Per my research, this fixes the bug (or, as VLC devs say, workarounds bugs in Qt and Mesa) which prevented VLC from correctly destroying its process when it was used with VDPAU hwdec and OpenGL renderer. This issue lead to disablement of VDPAU support in our package (R3140:99d8cc7ddccd33ed4b0594b7f62b2a30121ce54a). Given that this is now fixed in VLC (and it always exits properly at least on my system), should we enable VDPAU again?
For consideration - currently VDPAU is the only hwdec interface that VLC can use with Nvidia cards (since Nvidia doesn't support VAAPI and VLC 3.0.x doesn't support Nvidia Codec).

In D11025#182365, @aleksvor wrote:

Rebased after Samba/libupnp rebuild.