A longstanding complaint about KDE Plasma is that it’s a pain in the butt to stream videos that are located on Samba shares. It’s a usability issue for sure. I’d like to talk a bit about the origins of the problem and how I helped drive a solution.
Background
For KDE Plasma and apps, the KIO framework is responsible for file access and I/O–including files on Samba shares. Software that uses KIO gets this for free; for other software, KIO can either download the file locally before giving it to the program, or else give the program a Samba URL (e.g. smb://share/path/to/file.avi) and let the program figure out what to do.
KDE does have a KIO-aware video player that could do the job: DragonPlayer. Unfortunately, it’s not actively developed, and a bug prevents this from working.
That leaves 3rd party software, like VLC and MPV. These two don’t use KIO, but they do have Samba clients built in, so they’re able to handle the Samba URLs that KIO gives them!
The problem
…Unless the share is password-protected. In this case, the password must be added to the URL, like this: smb://user:password@share/path/to/file.avi. KIO won’t do that because tossing around user passwords in plaintext is an obvious security problem. So it’s up to the video players to either ask the user for the password to the Samba share, or look it up in the user’s KWallet.
The solution
Ideally, KIO would mount remote locations like Samba shares to a local path using FUSE, and then provide that path to non-KDE apps, which is what GNOME’s GVFs does (and why it works without drama in most GTK-based desktop environments). This would let any video player work with with no modifications, but that’s a task I’m not qualified to tackle, so I decided to attack the problem from another angle: make the most popular video players integrate with KWallet so they can prompt for the password and store it in the user’s wallet.
Unfortunately (but understandably), the MPV developers denied the request. But the VLC developers didn’t, and actually implemented KWallet support in VLC 3.0! But when I tested it using nightly builds of VLC 3.0, I found that it didn’t work, and had even regressed from version 2.
Apparently I was the first person to test the feature in VLC 3.0 beta builds. The VLC developers were a joy to work with, and soon enough, both issues were resolved! I re-tested with later builds and verified the fixes.
Behold, the power of QA!
Once VLC 3.0 is out, KDE Plasma users should be able to play videos located on Samba shares accessed with Dolphin. The first time you do it, VLC will ask you for the Samba share’s password:
After that, VLC will look up the password in your KWallet and you’ll never need to think about it ever again.
Lessons learned
QA is important. If people don’t test features, apps could ship broken.
Users like us are the QA. Most Linux software is not developed and sold commercially, and even distros with commercial backing do not have the resources to test most pre-release software. If we don’t test beta versions of our favorite software, we’ll end up doing it after the release once users are disappointed by bugs and broken features.
The easier you make it to test pre-release builds, the more people will do it and the better your volunteer QA will be. All of this was made possible because the VLC developers provide an Ubuntu PPA with nightly builds, so testing pre-release versions was easy and painless. This is great for Ubuntu users like me, but what about users of Debian, Arch, openSUSE, Fedora, or distros based on them? Had I been one of those users, I probably would have given up on doing this kind of testing.
This is why our work in Discover to make it easy to switch app versions is so important for the future. When every app has beta builds available with only a few clicks in a centralized location with a consistent interface, any user can easily become a beta tester.
Like what you see? Please consider testing beta builds of your favorite software and filing high-quality bugs if you find any issues–even ones that seem so obvious that you can’t imagine that the developers could have missed them. They might only be obvious on your hardware or with your use case! We may not pay for most of our software with money, but that just means developers need our time instead. The price of freedom is eternal QA.
Adventures in Linux and KDE 
Unfortunately, almost the first thing I do after installing Plasma on a new installation is disable KWallet. For many reasons, from double WiFi password prompts (https://bugs.kde.org/show_bug.cgi?id=387502) to confusing and frightening bugs like https://bugs.kde.org/show_bug.cgi?id=353960 and https://bugs.kde.org/show_bug.cgi?id=333137.
Sure, KDE PIM works if you take the time to set it up, but these tiny, even trivial bugs destroy professionality far more seriously than missing features. If the KDE community doesn’t have enough volunteers to maintain the PIM suite (the impression I get from the lack of Planet KDE posts), so be it. But increasing reliance on PIM in that case seems like a grave mistake…
LikeLike
And don’t forget https://bugs.kde.org/show_bug.cgi?id=389030!
You don’t need the whole PIM suite to make KWallet work. I use KWallet without it. I completely agree that those bugs harm the KWallet experience. But instead of giving up in KWallet, we need to fix them! That’s the only way we improve. We’d love your help, FWIW.
FWIW, The latter two bugs don’t appear in Kubuntu, or any other distro that configures KWallet to use the user’s login password by default. So to a certain extent it’s a distro configuration issue (and one big way to help is to petition your distro to set things up in a more humane way), but I agree that we need to improve the user experience of setting up a new wallet.
LikeLike
I think these bugs _explain_ the lack of contributions, actually. It’s an unpleasant responsibility to take on a software project that’s regarded as a nuisance. My 2¢: without people being paid to do whatever boring bugfixes and cleanups are necessary to give KDE PIM value in the eyes of users, KWallet & company will probably continue to stagnate. I hope I’m wrong, but I know that I don’t know enough C++ to even think about fixing it.
As far as distro configuration goes, Arch doesn’t do anything special in it’s kwallet PKGBUILD so in this case I think it’s the responsibility of KWallet to hard-depend on kwallet_pam if it’s necessary for the proper behavior.
LikeLike
The requirement is actually in the configuration: if you’ve got kwallet_pam installed, and there’s a wallet set up with the same password as your user password, everything magically works and you don’t have to go through the unpleasant set-up UI. Kubuntu seems to have something that does this automatically, and for other distros where users complain, I suspect that they don’t.
I’m going to try to hack on the current set-up UI to see if I can clean it up a bit. As for programming avbility, I’d never written a line of C++ before I decided to become a contributor. Lack of skill very rapidly becomes lots of skill if you’re motivated. And because KD software is all written in C++ with Qt, the skills are portable and useful outside of the FOSS community.
LikeLike
Well, that’s encouraging. I’d like to contribute to something KDE sometime…
LikeLike
Time or money, basically!
https://community.kde.org/Get_Involved#Ways_to_contribute
https://www.kde.org/community/donations/index.php
I mostly do time, but there’s always a way for anybody who cares to show it.
LikeLike
Glad to be able to finally play videos from a samba share in dolphin, seems to work well with vlc 3.0 it prompted me for the password and then played.
Curiously, I also see that this works with mpv as well which surprised me because to my knowledge they haven’t implemented kwallet support. But sure, enough I can browse to my samba share in dolphin and open a file in mpv and it immediately starts playing without any local file copy.
LikeLike
Well that’s interesting and positive! Did it prompt for a password?
LikeLike
It did not prompt for a password. I don’t know if that’s due to it somehow being passed the password from dolphin, or if I’m mistaken about how my samba share is setup (I’m pretty sure it requires a password because both dolphin and vlc prompted me when I first tried connecting to it)
LikeLike
Would it be possible to do the same for FTP? Streaming content via samba is easy and works, via FTP (which is usually a bit faster) I have had mixed success in the past.
LikeLike
“The easier you make it to test pre-release builds, the more people will do it and the better your volunteer QA will be.”
That’s another great argument for the sandboxed crossdistro flatpak and snap. It’s more secure and easier than ever to become a tester. Done correctly there will be more volunteers assuring the best user experience. The future of Linux looks less buggier and brighter!
LikeLike
looks like it is broken someware.. useing KUbuntu 18.04 LTS with vlc 3.0.3 – but I get “Operation not permitted” when I want to play from SMB share… Kodi had a similar problem – they said it is because W10 disabled smb 1.0 (which is ok) but question is
maybe it is the same problem on vlc – I also not get asked about user/pass.
LikeLike
ok, it looks only like it is not asking for user/pass… thats not so nice – when I define my user/pass in vlc settings – it is working.
but this looks not very secure to me.
LikeLike
Thanks a lot for your contribution on getting this sorted out.
Actually I am using VLC 3.0.4 but still not being able to fix this.
I can see in wallet the password saved for my smb share.
When trying to open the video VLC does not ask for any passwords though.
Kind of ran out of ideas. Any suggestions?
LikeLike