Updated: December 26, 2019
Here's an interesting problem for you. Remember my Asus Vivobook dual-booting Windows 8 and Ubuntu? Well, I had the machine upgraded from Trusty to Bionic, and in the course of further exercises, I also installed Plasma on the system. Everything was good, but then whenever I'd start Discover, I'd notice a message that shouldn't be there.
At the bottom of the Discover main screen, it would read: kdenlive_projectprofiles.knsrc" "Loading of providers from file: https://kdenlive.org/data/mltprofilesources.xml failed". Strange. Apart from this showing up for a few seconds, everything was working well. I was able to search for applications through Discover and install them, Kdenlive was working as expected. But my OCD demons wouldn't let this rest. So let's fix this, shall we.
Problem in more detail
Of course, I hit the intertubez to see what gives, and I found that lots of people were complaining about this over the past four or five years, with this or that application. Some would also experience wider issues, not being able to install software and alike. For me, the problem was restricted to a spurious message.
To learn more, I ran KDE Discover (plasma-discover) from the command line. This meant being able to see errors in more detail, including the full paths to any configurations or files that might be affected. The output wasn't clean, and there were several warnings for a whole bunch of things. But the one that's really interesting is this:
org.kde.knewstuff.core: "Error transferring https://kdenlive.org/data/mltprofilesources.xml - server replied: Not Found"
kns error "/etc/xdg/kdenlive_projectprofiles.knsrc" "Loading of providers from file: https://kdenlive.org/data/mltprofilesources.xml failed"
qml: message: kdenlive_projectprofiles.knsrc: Loading of providers from file: https://kdenlive.org/data/mltprofilesources.xml failed
error: "Expected '#' or '[a-zA-Z]', but got '&'." in QUrl("https://kdenlive.org/data/mltprofilesources.xml")
To verify whether this is a Plasma issue or a Kdenlive issue, I checked the listed URL, and indeed, it was returning 404. So Discover wasn't to blame here, something was missing on the application side. This also allowed me to narrow down my search.
Soon enough, I found this KDE bug - which was meant to fix the problem, and indeed, I should not have experienced the issue. But, here's the clincher, given the fact I've updated the distro from Trusty to Bionic, moving roughly four years in time in one afternoon, the configuration from my setup were carried over, and deprecated bits and pieces not really cleaned up properly.
If I understand the problem, the knsrc files are meant to reside under /usr/share, and the ones under /etc are not automatically deleted (due to the bug). So if you have old configurations, they might reference online resources or URLs that no longer exist (or have changed), which is quite likely when we're talking about big distro upgrades. And with these configurations in place, Discover throws errors.
Indeed, under /etc/xdg/kdenlive, the files were all relatively up to date (2018), except the one referenced in the errors kdenlive_projectprofiles.knsrc, which had last been changed in 2016. And therefore, the solution is to remove this file manually.
-rw-r--r-- 1 root root 244 Mar 10 2016
-rw-r--r-- 1 root root 1124 Mar 2 2018 kdenlive_wipes.knsrc
-rw-r--r-- 1 root root 1133 Mar 2 2018 kdenlive_titles.knsrc
-rw-r--r-- 1 root root 1197 Mar 2 2018 kdenlive_renderprofiles.knsrc
-rw-r--r-- 1 root root 48 Mar 2 2018 kdenlive.categories
Which I elegantly did (I actually moved it, so I would have a backup):
sudo mv /etc/xdg/kdenlive_projectprofiles.knsrc ~/backup/
And KDE Discover now ran without any errors. However, I think the proper solution to this should be a transparent change on the system level, without any user interaction. The whole thing needs better error handling. I am also confident that there aren't any side effects to this action, and yet, removing configuration files is never trivial, is it. Finally, the UI error is not useful, because it does not have a full path, and the presented information only confuses the user. If one needs the command line to see the actual file in question, then the error shouldn't be shown in Discover in the first place.
There we go. I can now rest again, because the system is error-free. I think this was a rather useful exercise, because it deals with a post-upgrade ghost that isn't instantly apparent - and which shouldn't be there, mind. Normally, I use the command-line interface to install software, so it took me a while to find this one out. And without any seemingly ill symptoms, this issue is problematic, because you can't be 100% sure the solution won't introduce future ghosts at some point.
But if you're facing issues of similar kind, then run Discover from the command line, try to pinpoint the error, then carefully examine the information to see whether the issue lines in the package manager or the referenced files (and remote sources). Once you've isolated the culprit, see whether removal or cleanup helps, but do make sure to have a backup, so you can easily revert. And I guess that would be all for this plasmatic article.