Debugging QML MediaPlayer

Hi everyone,

In gPodder we lately have an issue with several podcasts not working when trying to directly open their URL in the QML MediaPlayer object the error I get is not very helpful:

Error: "Secure connection setup failed."

At first I though this issue was due to a HTTP 30x redirect not being handled properly in an SSL session, however after refactoring the code so that the player gets the “final” targer of the redirect the problem persists.

I seem to only have this issue with 2 podcasts, using curl I am able to download the file properly and on my laptop I can play the URLs using mplayer.

Thus I am at a loss where things are going wrong and would like to get more detailed information from the QML process.

Any suggestions on accomplishing this are more then welcome.

An example of a URL that is not working (after redirect):


Anybody? Any ideas?

All help is welcome.

I have no clue why it’s happening, but it also happens with my Jellyfin client I wrote when I try to connect to, for example, It supports the minimum of TLS 1.2, according to which is from 2008. That should be still supported, right?

From some earlier error messages I had, I noticed gstreamer, the library that Qt MultiMedia uses, uses libsoup to do https request. Guess which version is installed? 2.4, which came out in 2008. libsoup depends on gnutls for TLS. And by executing pkcon search gnutls, I can safely say that this is very likely gnutls 2.12.24, which dates from 2016, which seems to be a patch made long (as in several years) after the gnutls 2.x branch was abandoned to improve future compatibility with TLS 1.2.

As far as I know, TLS 1.2 shouldn’t have had any major changes since later 2016 to cause it to break, right?

I wrote a quick (read: copied from the libsoup vala documentation) program to test things out:

using Soup;

int main (string[] args) {
    if (args.length == 1) {
        stdout.printf("USAGE: %s [URL]\n", args[0]);
        return -1;
    var url = args[1];
    stdout.printf ("HTTP GET %s\n", url);

    // create an HTTP session to twitter
    var session = new Soup.Session ();
    var message = new Soup.Message ("GET", url);

    // send the HTTP request and wait for response
    stdout.printf("Status: %u %s\n", message.status_code, message.reason_phrase);

    /*message.response_headers.foreach ((name, val) => {
        print ("%s = %s\n", name, val);

    // output the response to stdout 
    stdout.write (;*/
    return 0;
  1. Save this as http-test.vala on your device
  2. make sure libsoup-devel, vala and gcc are installed (pkcon install libsoup-devel vala gcc).
  3. Runvalac http-test.vala --pkg libsoup-2.4, which should create a file name http-test, which is executable.
    4.Now you should be able to execute GET requests with libsoup by running ./http-test [url]. It should print out the HTTP status code of the request if everything goes alright, otherwise it prints out a code smaller than 100 with an error message.

And guess what, the old libsoup seems to be the cause! When I try to make a request to “”, I get back “Status: 6 Peer failed to perform TLS handshake”.

So my assumption is that the problem lies within the old versions of libsoup and libgnutls.

1 Like

Wow great research!

I’m guessing you are not yet on SFOS 3.4 or that there is a difference between models because on my Xperia X libsoup is 2.68 (at least according to rpm).

But gnutls is still at version 2.12.24 and I’m guessing that upgrading it will be a major upgrade :frowning: @vige?

You’re right. Libsoup’s version is 2.68, but the API has stayed on 2.4 for quite some time now and hasn’t been changed it seems.

I am no expert on libsoup so I may be wrong in my interpretation, but when I browse through the GNOME documentation on libsoup the URLs strongly suggest that the API is still version 2.4 which makes sense since as a developer you want you API to be as stable as possible so that your users don’t suffer.

BTW - back in 2014 NielDK released gnutls 3.2.12 for SFOS (on OpenRepos) so it may not be that hard to get onto the phone though I guess that would not resolve the issue of QML being compiled against gnutls 2.12.24 and these libs are not binary compatible (the API/ABI changed which is why they switched major versions)