Bug 253547

Hmm, how did this work before?
Does VLC really support sftp:// URLs? How? It has KIO integration?

Huh, you're right, VLC does not support sftp, I was pretty sure it did. Well, I'm 100% sure it does work with smb, I already tried it.
I also found out that with ftp, VLC is launched correctly, so this might be SMB specific. I'll try out some more later today, I don't have time right now.

OK then it's clear: what's missing is

X-KDE-Protocols=http,ftp,smb

in vlc's .desktop file.
It sucks a bit that we have to ask other people to modify their desktop files like this, but how else can we know which protocols these apps support...

[the reason it works already with http and ftp, is that those are the fallbacks assumed by the KIO code when there's no X-KDE-Protocols line, in the .desktop file for a non-kde app]

Yeah, that was it - I modified the .desktop file and now it's working. There should be some howto somewhere, I could not find anything. So I guess this bug is solved invalid?

Maybe this is not the right place to ask, but I'll do so anyway.

Why isn't there a unified variable for all DEs? Like "Protocols" or something? Are some protocols different in usage across the DEs (different links)?

/usr/share/kde4> find . -name "*desktop"|xargs grep 'X-KDE-Protocols'
 
found the only 
X-KDE-Protocols=KIO
in
./services/konqueror.desktop:X-KDE-Protocols=KIO
./servicetypes/application.desktop:[PropertyDef::X-KDE-Protocols]

nevertheless I think it never worked (well) in KDE4

> Why isn't there a unified variable for all DEs? Like "Protocols" or something?
> Are some protocols different in usage across the DEs (different links)?

You ask the question and provide part of the answer just afterwards :-)

But I just posted a request for this, see http://markmail.org/thread/6miwiobj6hyp5o4o

About a howto: if there was one about X-KDE-Protocols on techbase or userbase, would you have found it? Ideally this isn't something users would need to tweak, but rather that should be done correctly in all .desktop files (of apps which open urls). This will take a bit of time though... First, to get this into the spec (hopefully) and then for people providing .desktop files (or distros) to make them right. I don't see any other solution though.

Created attachment 53068 [details]
example

Have this problem in 4.5.2 too. Also I can't open https link from kmail.

https should be added to the fallback protocols. There is hardly any application that supports http but no https. But of course, this is not a solution to the actual problem.

https has been added to the fallback protocols, see bug 253294.

Hi all,

are we sure the bug is not this issue here 

http://reviewboard.kde.org/r/5280/diff/

where support protocols were removed for smb from krun.ccp ?

For further reading and fix see here:

http://blog.jfdesignnet.com/?p=1281

Thank Lubos Lunak for the screw up.

Dragon32:
1) please calm down and try to understand the issue.
2) yes the behavior was changed by this commit, intentionnally. We can't guess which applications support which protocols, we need the application to tell us, and it can do that, using its .desktop file
3) the correct solution for smb to work again in e.g. vlc is to add X-KDE-Protocols=smb in vlc.desktop

Hello David,

thank you for the reply and letting me know that you are aware of this 
issue.

I think it is going to be a difficult strategy asking less adept users 
to individually alter each .desktop file to regain functionality, I hope 
a more permanent and simpler solution can eventually
be found to this problem that satisfies the requirements for all.

A suggestion might be a simple config file  where krun.ccp behaviour can 
be modified by the user easily.


Thanks



On 17/11/10 12:49, David Faure wrote:
> https://bugs.kde.org/show_bug.cgi?id=253547
>
>
>
>
>
> --- Comment #13 from David Faure<faure kde org>   2010-11-17 13:49:26 ---
> Dragon32:
> 1) please calm down and try to understand the issue.
> 2) yes the behavior was changed by this commit, intentionnally. We can't guess
> which applications support which protocols, we need the application to tell us,
> and it can do that, using its .desktop file
> 3) the correct solution for smb to work again in e.g. vlc is to add
> X-KDE-Protocols=smb in vlc.desktop
>

I'm not asking users to edit files, I'm asking that someone fixes vlc.desktop upstream once and for all :-)

I just checked and it's part of the git sources for vlc.
Before I make a patch for them to merge, I just asked again on the XDG list about adding a non-kde-specific key to the desktop entry standard, calling it UriSchemes instead.

Changing krun's behavior is the wrong place: OpenOffice.org doesn't support smb urls, VLC does, so this information has to come from the .desktop file of the application.

BTW I have (solved) a similar problem with Gwenview adding
X-KDE-Protocols=smb,ftp,sftp to the desktop file

may be someone can look into this

I forgot to say - I could open a file from smb with gwenview, but then next/prev button didn't work

Gwenview shouldn't need this, its desktop file says Categories=Qt;KDE;... which tells krun that it supports all kio protocols. Do you have a different gwenview.desktop file (e.g. in .local/share/applications?)

only ONE gwenview.desktop in [/usr , ~/.kde4]

BTW could it be a similar issue that it is not possible to attach smb/sftp/fish files to sites like bugs.launchpad.net ?

I always get the error "You can only select local files" (translated from German)

#19: well, does it have Categories=KDE?

#20: no, that's completely unrelated to starting applications, that's the support for file input fields in KHTML, please open a new report for that if there isn't already one.

#19: no  "Categories=KDE" is (still) missing
after adding this it works (again)

Well, please find out why :)
kdegraphics/gwenview/app/gwenview.desktop has had Categories=KDE since its creation, in September 2007. So the file you're looking at... comes from somewhere else (?)

the only one is here on OpenSuSE 11.3 KDE 4.5.3
/usr/share/applications/kde4/gwenview.desktop

Now I have the same problem with Konqueror. If I click a link in KMail or Amarok, they download the web page, and Konqueror opens a file under /var/tmp/kdecache...

it's still not solved in 4.6.5 :-(

had to add
X-KDE-Protocols=http,ftp,smb + some more protocols like fish etc
in
/usr/share/applications/kde4/gwenview.desktop

I just installed
gwenview-4.6.5-11.1 OpenSuSE 11.4
and had to add
X-KDE-Protocols=http,ftp,smb,fish
to 
/usr/share/applications/kde4/gwenview.desktop
to allow next/previous image to work

*** Bug 262894 has been marked as a duplicate of this bug. ***

>We can't guess which applications support which protocols, we need the application to tell us, and it can do that, using its .desktop file

Why this should be done in this way at all? 

Trying to work with protocols in this way brings so many problems even to kde native apps (and this report shows it clearly) and non-kde apps are just out of the boat in most cases - vlc will not support sftp, other app will not support another protocol etc. How should the user guess while browsing smb share if he can open file X with program Y? Why should he guess at all if program Y works with file X just file when the file is outside smb share (in his home dir).

And even if it support it, is it guarantied, that it would work with it in the way any other kde application does (for example would use saved password for smb shares)?

Why not using transparent fuse mounts for all that cases removing the problem once and for all?

*** Bug 294840 has been marked as a duplicate of this bug. ***

Related problem:
If user is changing command-line for application in file-associations systemsetting - this leads to creating new desktop-file in ~/.local/share/applications, and that desktop file is missing "X-KDE-Protocols=KIO" or "Categories=KDE;" lines.
That leads to this bug: https://bugs.kde.org/show_bug.cgi?id=286717
Kate becomes unable to handle remote files correctly

*** Bug 306860 has been marked as a duplicate of this bug. ***

*** Bug 282963 has been marked as a duplicate of this bug. ***

I've the same issue with my arch linux system with kde 4.9.5.
In my case the /usr/share/applications/vlc.desktop already has the X-KDE-Protocols line (the last lines of the file are reported below), however it continues to save locally the remote file before playing it.

Exec=/usr/bin/vlc %U
TryExec=/usr/bin/vlc
Icon=vlc
Terminal=false
Type=Application
Categories=AudioVideo;Player;Recorder;
MimeType=video/dv;video/mpeg;video/x-mpeg;video/msvideo;video/quicktime;video/x-anim;video/x-avi;video/x-ms-asf;video/x-ms-wmv;video/x-msvideo;video/x-nsv;video/x-flc;video/x-fli;video/x-flv;video/vnd.rn-realvideo;video/mp4;video/mp4v-es;video/mp2t;application/ogg;application/x-ogg;video/x-ogm+ogg;audio/x-vorbis+ogg;application/x-matroska;audio/x-matroska;video/x-matroska;video/webm;audio/webm;audio/x-mp3;audio/x-mpeg;audio/mpeg;audio/x-wav;audio/x-mpegurl;audio/x-scpls;audio/x-m4a;audio/x-ms-asf;audio/x-ms-asx;audio/x-ms-wax;application/vnd.rn-realmedia;audio/x-real-audio;audio/x-pn-realaudio;application/x-flac;audio/x-flac;application/x-shockwave-flash;misc/ultravox;audio/vnd.rn-realaudio;audio/x-pn-aiff;audio/x-pn-au;audio/x-pn-wav;audio/x-pn-windows-acm;image/vnd.rn-realpix;audio/x-pn-realaudio-plugin;application/x-extension-mp4;audio/mp4;audio/amr;audio/amr-wb;x-content/video-vcd;x-content/video-svcd;x-content/video-dvd;x-content/audio-cdda;x-content/audio-player;application/xspf+xml;x-scheme-handler/
mms;x-scheme-handler/rtmp;x-scheme-handler/rtsp;
X-KDE-Protocols=ftp,http,https,mms,rtmp,rtsp,sftp,smb
Keywords=Player;Capture;DVD;Audio;Video;Server;Broadcast;

I agree with  anton, this ridiculousness with kio is a huge pain compared to the way gnome does it (mounting the share with gvfs/fuse).

The way gnome does it works with EVERY SINGLE APPLICATION.

With kde I can't even do a simple task like streaming a video from a smb share, even with kde's default dragonplayer.

Who is in charge of kio development?

This is still present in ubuntu 13.04 KDE spin and Fedora 19 KDE spin (4.10.5). adding the protocols to vlc.desktop in home directory and under /usr/share/applications/ doesn't solve the problem.

For months (years...) I've installed KDE now and then to see if this functionality was fixed. So far, even with Kubuntu 13.04 and KDE 4.11, no dice. All of my systems are now running smaller drives due to them being SSDs, so I keep no media on any of my systems. Instead, I stream it from my server, which works fabulously with Gnome. I hate to pull the comparison card, but I'm just speaking realistically. While KDE is turning into a rather well rounded environment, things like this hold it back immensely. Unfortunately, KDE is not suitable to be a primary choice of environment as streaming media has turned into a must-have feature.

What KDE badly needs to remedy this is some equivalent to GVFS (or why not just use GVFS)? With gvfs the share is just treated as a local drive, therefore EVERY SINGLE APPLICATION has no problem accessing/streaming files and such. KDE's kio implementation seems to rely on the application itself fully supported kio which is a huge limitation, and even native kde apps like dragonplayer don't seem to properly support this.

On the windows box that my media was on I ended up having to enable the windows http server with directly browsing to workaround this. That way I can open smplayer ctrl + u and paste the http link and stream it.

Please find a solution!
KDE is far too amazing to let this bug not fixed.

> KDE's kio implementation seems to rely on the application itself fully supported kio which is a huge limitation, and even native kde apps like dragonplayer don't seem to properly support this.

New android tablets use mtp protocol without mounting sd-card as removable device, and kde supports its rather well, but with "mtp://" kio url, so Dolphin does not generate thumbnails for the photos on the mobile Device (because it is not local) and Gwenview does not provide "prev/next" button when open single photo from the device. This is total regression (how would I browse my photos on the smarphone without copying them all to hard disk?) and it seems there is no way to fix all those problems until kio url-styled paths are priority by-design.

Can someone please clarify the status of this bug?

Reading the initial bug report and up to comment #5 I understand the issue is with the .desktop files and can be fixed there?

If you know of an application that understands remote "protocols" as arguments, and those are specified in its .desktop file, but are still called with a temporary file instead of the remote argument, please add exact steps to reproduce (name and version of the application, contents of its .desktop file, used protocol in Dolphin, etc.)

I've tried with my updated arch linux system and the problem seems resolved at least with vlc which has the X-KDE-Protocols line in its .desktop file

Last I tried, gwenview still had problems related to this bug. With a cifs mounted share, next and previous worked fine on gwenview, but with a smb share mounted through dolphin, next and previous images were buggy, and it would not see all the images correctly. This was in 4.14.

The recent news about Plasma 5 had me interested to try it out again. I fired up Kubuntu 14.10 Plasma 5 Preview (not the standard 14.10 ISO) and installed it. I linked up to a Samba share which contained mp3 and mp4 files. Here's what I found.

Opening an mp4 file to Dragon does nothing. Dragon appears to have no idea what to do.

Opening an mp3 file to Dragon does nothing. Dragon appears to have no idea what to do.

Opening mp3 file to Amarok (default) caches the file in /var/tmp/kdecache.jason/something/something. It seems to do a full download of the file in /var/tmp/.../... before playing in Amarok, however it does play successfully. Upon a system restart, the files were still in /var/tmp, which concerns me a bit for users who might play an endless array of files over the network, thereby spiking the cache and inevitably diminishing the HDD space for root (especially if they have root sitting on a smaller partition split from home).

I installed VLC (from Muon, which seems to be 2.2.0-pre2 Weatherwax), which seemed to take over as default from the get-go (I suppose, anyway, as I didn't make it default). Clicking the mp4 on the Samba share opens in VLC instantly. It does not notify me about caching the file, nor would it be possible for it to cache a several-hundred-MB file over wireless in a split second, because as I mentioned it begins playing the video instantly.

I did not edit the VLC desktop file, however the VLC desktop file reads as such when I did a grep for "smb"
jason@laptop:~$ cat /usr/share/applications/vlc.desktop | grep smb
X-KDE-Protocols=ftp,http,https,mms,rtmp,rtsp,sftp,smb

Am I correct with my understanding that basically this issue still exists at a KDE level but thanks to VLC adding this into the desktop file, it's thereby a workaround for KDE/VLC users?

Anyway, just wanted to share my findings in case it was of any assistance.

It's worth mentioning that my experience listed above might have been a fluke. Following some issues with my testing last night, I did a fresh install just as I had done before. Afterwards I went to stream some videos from my file server and to my surprise, it wasn't able to accomplish this task, whereas before it had. I checked the VLC desktop file and it was identical to what my other install had that worked under VLC. Still, no dice.

I'll try KDE again when (if) this bug is fixed. Until then, simple things like the inability to play multimedia over the network is a bit of a show stopper. Thanks for your time.

Created attachment 89941 [details]
attachment-23890-0.html

Hi Jason,

sorry to be so late :)

My arch is not up to date, so I can't check right now. By the way it is way
more than a year that this goes on, honestly I'm thinking to change my DE
since with for example raspbmc I have NO problems mounting samba shares and
streaming videos (tested yesterday night with my brand new raspi :D)

A lot of time ago I tried adding that X-KDE-Protocols thing to every
players' .desktop in my system but it did nothing...

many thanks for letting me know what you tried, and please if you find out
something let me know: i'll do the same! :D

Dario

2014-11-25 15:07 GMT+01:00 Jason Sauders <jasauders@gmail.com>:
>
> https://bugs.kde.org/show_bug.cgi?id=253547
>
> --- Comment #46 from Jason Sauders <jasauders@gmail.com> ---
> It's worth mentioning that my experience listed above might have been a
> fluke.
> Following some issues with my testing last night, I did a fresh install
> just as
> I had done before. Afterwards I went to stream some videos from my file
> server
> and to my surprise, it wasn't able to accomplish this task, whereas before
> it
> had. I checked the VLC desktop file and it was identical to what my other
> install had that worked under VLC. Still, no dice.
>
> I'll try KDE again when (if) this bug is fixed. Until then, simple things
> like
> the inability to play multimedia over the network is a bit of a show
> stopper.
> Thanks for your time.
>
> --
> You are receiving this mail because:
> You voted for the bug.
> You are on the CC list for the bug.
>

Hello friends. In hopes that perhaps Plasma 5 would somehow bring new changes to this issue, I fired up Kubuntu 15.04 (which is currently in alpha I believe), which is running 4.14 with Plasma 5. Unfortunately, no dice. I still cannot stream videos over the LAN whatsoever. I click the video and nothing at all happens.

Won't be long and this report will be 5 years old...

(In reply to Jason Sauders from comment #48)
> Hello friends. In hopes that perhaps Plasma 5 would somehow bring new
> changes to this issue, I fired up Kubuntu 15.04 (which is currently in alpha
> I believe), which is running 4.14 with Plasma 5. Unfortunately, no dice. I
> still cannot stream videos over the LAN whatsoever. I click the video and
> nothing at all happens.
> 
> Won't be long and this report will be 5 years old...

You are wasting your breath, it seems that nobody cares about this. As this is open source project, everybody involved works on things they find interesting, and there is no one to hear your complaint. 

And I believe everybody that could have solved this would rather manually mount smb share, rather than spend little more time to automate this process.

As always you can hear the reply: "Learn to code and fix it yourself"

Please read comment #42 and add *all* *exact* information to reproduce it.

Back when I used gnome2, nautilus would just mount the network share using gvfs and everything would work fine in every application as far as streaming went. Now I have to mount it using mount.cifs to be able to accomplish anything. What is stopping kde from abandoning the broken whatever it is that it is using now (kio?) and switching to just having dolphin automount the shares like gnome2 did? It doesn't seem like it would be hard to do.

> What is stopping kde from abandoning the broken whatever it is that it is using now (kio?) and switching to just having dolphin automount the shares like gnome2 did?

Your comment is completely unrelated to this bug report, so please start a separate thread in the KDE forums.

> It doesn't seem like it would be hard to do.

That's what I read every day.

For what it's worth, I fired up my Kubuntu 14.10 Plasma 5 install and began to tinker around more. It's worth mentioning that this bug extends a bit deeper than just multimedia. I cannot open any LibreOffice documents sitting on a network share if I mount shares in the standard smb://server/share type of way. It tries but LibreOffice eventually times out. Given how popular home servers are getting with the Synology/FreeNAS/OpenMediaVault setups of the world, it's more common now to centrally house multimedia and documents like this, even at the home level. I find that using smb4k along with KDE is really the only way I would consider using KDE full time, as smb4k handles the network shares in a more consistent manner that actually restores usability. 

Given the Plasma 5 target along with things getting more and more refined and well put together (truth be told, I absolutely love what I am seeing from Plasma 5), this sort of functionality is all-but expected when users hop on "name any distro/DE/OS here." 

I can't code, or else I'd be all over this. Is there a bounty process we can contribute to? I'd dish out some green to see this 5 year old bug fixed.

I am tempted to nominate this bug as the "Bug of The Month" for March. This would raise the number of eyes that will see it.

This does, however, require that this bug is reproducible, and is not caused by wrong configuration in all participating components. In other words, you must be able to supply all requested files, logs, version numbers or settings to developers.

Since comment #43 seems to suggest that it "just works" with recent versions, we need to find out why it does not work for you.

I think this is one of the most annoying bugs in KDE.
When a non-technical user uses KDE and wants to access data on a network share - which is REALLY common nowadays, he has to know the internal design of KDE and KIO slaves.

Because most of the time, things just DON'T work.
I'm running KDE 4.14.3 and on samba shares I
- cannot open libreoffice documents
- cannot open videos (kaffeine, dragonplayer, vlc works because it uses it's own samba handling)
- i'm pretty sure most other non-kde applications won't work with files on samba shares, too.

What works is gwenview, okular, i guess most other KDE apps.

I think limiting the use of network shares on a KDE desktop environment to (most) KDE applications is a bad design decision.

As for this specific bug: VLC plays my files from samba shares IF i specify the username and password to use in the VLC preferences.

I vote for closing this bug and switching from KIO to GVFS.

This bug used to affect me also, but since then I haven't had to stream stuff very often.. So I decided to try it now just as a test, and it seems just like comment #43 said, it just works for me now, so I am not sure why comment #55 is having problems with it..

I am on debian jessie, using KDE 4.14.2, and I can successfully stream movies from the raspberry-pi (it has a samba server running on it).. I am using smplayer (like I always have).. The movie starts playing with out downloading it, and the address in smplayer says smb://blahblah (instead of a local address on the computer playing a temp file)..

My results on KDE 4.14.3, OpenSUSE 13.1, trying to open mkv video file through smb:// (opened shared folder with Dolphin)

VLC, Smplayer - correctly streaming video without downloading
Smplayer2 - does not stream, starts downloading video file to /var/tmp/kdecache-user/

I checked .desktop files for Smplayer2 and Smplayer and they both look correct (both have X-KDE-Protocols=http;ftp;smb)
Smplayer2.desktop: http://paste.opensuse.org/38477177
Smplayer.desktop: http://paste.opensuse.org/10758386

The same behavior is with mp3 audio files (VLC, Smplayer streaming ok, but Smplayer2 does not), Amarok also works fine (streams without download)

In reply to comment #56:
While it's nice that smplayer and VLC works, did you try kaffeine/dragon player?
Also, did you try it with a password protected samba share?

And as i said, this very specific bug may be fixed, but the general issue remains (non-KDE apps like libreoffice).

@comment #58:
I only tried smplayer, but just now I decided to try the other players you mentioned to see if they would work or not..

smplayer: works fine and streams..
dragon player: works fine and can stream also..
kaffeine: could stream fine also..
vlc: VLC refuses to run for me.. It says "VLC is not supposed to be run as root.", but I don't have any other accounts on my computer besides the root one.. But I don't use stupid VLC any way..

All of the 3 players that worked show the address as "smb://whatever", and don't have to copy any files, they just start playing essentially instantly (with in like 5 seconds).. I am testing huge movies too (like 2.4GB movies and stuff), so there is no way a movie would transfer that fast.. Plus, when I seek in the movie, it has to buffer for a few seconds (because it is streaming, and not a local copy)..

One thing I didn't test though is password-protected samba shares.. I had a hell of a time just getting samba to work (on raspberry-pi) with just public guest access, so I don't even feel like messing with passwords and stuff.. But I would imagine that if you could first get your set-up to work with a publicly-shared samba share first, then you could try adding password next maybe?..

I just did a fresh install of Kubuntu 14.10 Plasma 5 preview and tested several scenarios. This is a brand new installation, no major tweaks or changes, fully updated with only a few multimedia applications installed specifically to test this bug. I checked Kubuntu 14.10 with the standard Plasma 4 setup several weeks ago with the same results.

The server is running OpenMediaVault, which is based on Debian Stable. It's running a standard Samba setup with user accounts, passwords for the users, etc. The Kubuntu client connects by opening Dolphin, CTRL + L, and types in smb://ip.to.smb.server, then authenticates upon clicking on the share in question. Here is a quick snapshot of my share within smb.conf for reference.

[Public]
path = /media/2f933da3-223d-473f-af39-de955f3158ef/Public/
guest ok = no
read only = no
browseable = yes
inherit acls = yes
inherit permissions = yes
ea support = no
store dos attributes = no
printable = no
create mask = 0755
force create mode = 0644
directory mask = 0755
force directory mode = 0755
hide dot files = yes
valid users = "guest","htpc","jason","kristi"
invalid users = 
read list = 
write list = "guest","htpc","jason","kristi"

My Findings:

VIDEOS (MP4)
smplayer - application opens, but effectively does nothing else with no playback.
VLC - application opens, but effectively does nothing else with no playback.
Dragon - application opens, but effectively does nothing else with no playback.

MUSIC (MP3)
Amarok - application opens, but copies the file locally, citing "copied to /var/tmp/kdecache" in the notification menu.
Clementine - application opens, but copies the file locally, citing "copied to /var/tmp/kdecache" in the notification menu.
Audacious - application opens, but copies the file locally, citing "copied to /var/tmp/kdecache" in the notification menu.
VLC - application opens, but throws an error "unable to open the MRL"

DOCUMENTS (.ODT)
LibreOffice Writer - Once I click on an ODT file, I see in the panel that LibreOffice Writer is attempting to open. In the end, it does not open and the spinning entry in the panel ultimately disappears.

Same here as described in #c60, additionally tried current Arch Linux as a client and sftp as protocol. sftp might be easier to reproduce, as it only requires a working ssh server instead of a full-fleged samba.

I'm shocked that this issue is still there even in an up to date KDE neon. A lot of people I know that are not IT-experts but just users came to KDE because of the awesome "KDE connect", but nearly all of them went back to their previous desktop because of this bug.
What's causing the stall on this, what can I do to help (I can't code though)?

Your comment does not add any information. Reading the previous comments, people got it working with different applications and different protocols, and it is not clear which issue you see.

First, make sure the application actually supports the protocols (http:, ftp:, sftp:, smb: etc.) you feed to it. You can test it on the command line.

Applications that use the KDE frameworks should support them. If not, please report this issue to the developers of the application.

Next, make sure those supported protocols are actually stated in the desktop file.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

To me this bug seems to be fixed. On a pretty much virgin KDE neon 5.13 system with VLC 2.2.2 installed it's all working for me. I do not have any credentials entered into either System Settings -> Connections -> SMB Access and neither VLCs SMB access-module.
The only annoyance is that Dolphin sometimes stays focused when launching a media file instead of VLC showing up in the foreground.

Ok, I'll mark this resolved. If there is still an issue, please feel free to reopen.