Bug 253547 - Regression: since 4.5.2, KDE downloads multimedia files instead of letting applications stream them
Summary: Regression: since 4.5.2, KDE downloads multimedia files instead of letting ap...
Status: RESOLVED WORKSFORME
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: 4.5
Platform: Compiled Sources Linux
: VHI normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: triaged
: 262894 282963 294840 306860 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-10-07 22:35 UTC by Malte Eggers
Modified: 2018-09-28 16:59 UTC (History)
25 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
example (158.45 KB, image/png)
2010-11-02 11:39 UTC, Alexander
Details
attachment-23890-0.html (2.07 KB, text/html)
2014-12-12 19:18 UTC, Dario
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Malte Eggers 2010-10-07 22:35:59 UTC
Version:           4.5 (using Devel) 
OS:                Linux

When I open files on the network (I tried SMB and SFTP so far), KDE downloads the file to /var/tmp/kdecace-<user>/krun and launches the application with the downloaded file, instead of passing the link to the application and letting it stream the file. This does neither depend on the application the file is opened from, nor on the application the file is to be opened in. All the applications I tried have %U as an argument, which should make KDE launch the application with the direct URL.

Reproducible: Always

Steps to Reproduce:
1. install KDE 4.5.2
2. open any network directory in any browser (for example, in dolphin, sftp to your own computer) and launch any multimedia file with some application that has %U as argument (for example VLC).

Actual Results:  
the file is downloaded and then the application is launched, playing the downloaded file

Expected Results:  
the application should have been launched directly, streaming the file from the network.

Please add the entry "4.5.2" to KDE Version, so I can be more specific.
Comment 1 David Faure 2010-10-08 01:08:29 UTC
Hmm, how did this work before?
Does VLC really support sftp:// URLs? How? It has KIO integration?
Comment 2 Malte Eggers 2010-10-08 08:27:03 UTC
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.
Comment 3 David Faure 2010-10-08 12:46:03 UTC
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...
Comment 4 David Faure 2010-10-08 12:46:43 UTC
[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]
Comment 5 Malte Eggers 2010-10-09 10:57:14 UTC
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?
Comment 6 Malte Eggers 2010-10-10 16:12:35 UTC
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)?
Comment 7 Ferdinand Gassauer 2010-10-10 16:20:18 UTC
/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
Comment 8 David Faure 2010-10-11 14:22:39 UTC
> 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.
Comment 9 Alexander 2010-11-02 11:39:24 UTC
Created attachment 53068 [details]
example

Have this problem in 4.5.2 too. Also I can't open https link from kmail.
Comment 10 Malte Eggers 2010-11-02 12:28:01 UTC
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.
Comment 11 David Faure 2010-11-03 01:05:05 UTC
https has been added to the fallback protocols, see bug 253294.
Comment 12 Dragon32 2010-11-17 12:53:06 UTC
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.
Comment 13 David Faure 2010-11-17 13:49:26 UTC
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
Comment 14 Dragon32 2010-11-17 14:12:39 UTC
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
>
Comment 15 David Faure 2010-11-17 15:28:55 UTC
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.
Comment 16 Ferdinand Gassauer 2010-11-17 21:41:28 UTC
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
Comment 17 Ferdinand Gassauer 2010-11-17 21:48:05 UTC
I forgot to say - I could open a file from smb with gwenview, but then next/prev button didn't work
Comment 18 David Faure 2010-11-18 11:44:44 UTC
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?)
Comment 19 Ferdinand Gassauer 2010-11-18 12:57:05 UTC
only ONE gwenview.desktop in [/usr , ~/.kde4]
Comment 20 Ferdinand Gassauer 2010-11-18 14:58:10 UTC
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)
Comment 21 David Faure 2010-11-18 15:13:44 UTC
#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.
Comment 22 Ferdinand Gassauer 2010-11-18 22:48:12 UTC
#19: no  "Categories=KDE" is (still) missing
after adding this it works (again)
Comment 23 David Faure 2010-11-18 23:45:34 UTC
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 (?)
Comment 24 Ferdinand Gassauer 2010-11-19 00:23:43 UTC
the only one is here on OpenSuSE 11.3 KDE 4.5.3
/usr/share/applications/kde4/gwenview.desktop
Comment 25 Alexander Potashev 2010-11-21 21:46:05 UTC
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...
Comment 26 Ferdinand Gassauer 2011-07-09 14:25:48 UTC
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
Comment 27 Ferdinand Gassauer 2011-07-27 06:56:04 UTC
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
Comment 28 Jekyll Wu 2011-12-02 22:28:58 UTC
*** Bug 262894 has been marked as a duplicate of this bug. ***
Comment 29 anton 2011-12-02 22:45:29 UTC
>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?
Comment 30 Christoph Feck 2012-02-26 18:37:56 UTC
*** Bug 294840 has been marked as a duplicate of this bug. ***
Comment 31 Evstifeev Roman 2012-08-17 16:28:08 UTC
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
Comment 32 Jekyll Wu 2012-09-21 11:50:34 UTC
*** Bug 306860 has been marked as a duplicate of this bug. ***
Comment 33 Dawit Alemayehu 2012-10-16 22:25:08 UTC
*** Bug 282963 has been marked as a duplicate of this bug. ***
Comment 34 Xwang 2013-01-22 21:34:23 UTC
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;
Comment 35 Brandon Watkins 2013-06-01 14:59:33 UTC
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.
Comment 36 illumilore 2013-06-02 06:12:59 UTC
Who is in charge of kio development?
Comment 37 Otso Helenius 2013-08-08 16:19:54 UTC
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.
Comment 38 Jason Sauders 2013-08-19 18:45:58 UTC
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.
Comment 39 Brandon Watkins 2013-08-19 19:20:30 UTC
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.
Comment 40 Dario 2013-11-23 22:11:17 UTC
Please find a solution!
KDE is far too amazing to let this bug not fixed.
Comment 41 anton 2014-02-21 18:55:00 UTC
> 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.
Comment 42 Christoph Feck 2014-10-26 00:19:49 UTC
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.)
Comment 43 Xwang 2014-10-26 09:27:14 UTC
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
Comment 44 illumilore 2014-10-26 17:28:39 UTC
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.
Comment 45 Jason Sauders 2014-11-24 16:23:45 UTC
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.
Comment 46 Jason Sauders 2014-11-25 14:07:51 UTC
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.
Comment 47 Dario 2014-12-12 19:18:07 UTC
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.
>
Comment 48 Jason Sauders 2015-01-30 06:04:40 UTC
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...
Comment 49 Mirza 2015-01-30 06:39:31 UTC
(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"
Comment 50 Christoph Feck 2015-01-30 10:16:44 UTC
Please read comment #42 and add *all* *exact* information to reproduce it.
Comment 51 illumilore 2015-01-30 18:44:51 UTC
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.
Comment 52 Christoph Feck 2015-01-30 18:57:09 UTC
> 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.
Comment 53 Jason Sauders 2015-01-30 19:19:55 UTC
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.
Comment 54 Christoph Feck 2015-02-15 19:22:25 UTC
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.
Comment 55 Julian Kalinowski 2015-02-15 22:30:30 UTC
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.
Comment 56 Baconmon 2015-02-16 00:10:32 UTC
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)..
Comment 57 Evstifeev Roman 2015-02-16 14:06:58 UTC
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)
Comment 58 Julian Kalinowski 2015-02-16 15:41:17 UTC
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 59 Baconmon 2015-02-17 00:21:26 UTC
@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?..
Comment 60 Jason Sauders 2015-02-17 02:35:50 UTC
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.
Comment 61 Florian Jacob 2015-02-24 22:57:08 UTC
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.
Comment 62 villeneuve 2016-12-30 16:17:34 UTC
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)?
Comment 63 Christoph Feck 2016-12-30 16:44:29 UTC
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.
Comment 64 Andrew Crouthamel 2018-09-28 02:37:49 UTC
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!
Comment 65 villeneuve 2018-09-28 10:47:28 UTC
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.
Comment 66 Andrew Crouthamel 2018-09-28 16:59:15 UTC
Ok, I'll mark this resolved. If there is still an issue, please feel free to reopen.