Videos on Samba shares

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.

Advertisements

11 thoughts on “Videos on Samba shares

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

    Like

    1. 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.

      Like

      1. 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.

        Like

        1. 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.

          Like

  2. 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.

    Like

      1. 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)

        Like

  3. 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.

    Like

  4. “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!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s