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:
plasma-discover
…
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.
Solution
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
kdenlive_projectprofiles.knsrc
-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.
Conclusion
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.