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.
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!
…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.
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.
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.