@invernosantigos

I got a solution, if I can call it that, because I didn't solve anything. The problem is a bug in the flatpak version. So I just installed via apt and then uninstalled flatpak. Now why is it a bug? Because the problem doesn't happen with Strawberry Player installed in the root of the system, only in the flatpak. I had tried it before, but opted for flatpak despite the risks, only the regular version (installed via apt) didn't work, and it waved an error message indicating a missing gstreamer plugin - actually the uridecode, which makes plugins work . gstreamer has always been bad, since the 90's, for the total lack of user support. Searching the internet, it looks like there's ample support on gstreamer.org, but no... the support there is for developers only, in that unintelligible developer jargon.

Now, if something doesn't even support the basics and the most common problems, it sucks, right? That's irresponsible and sloppy, which is why I've always been against donating to gstreamer.org.

worse because in addition to the lack of support, gstreamer problems tend to be unsolvable. All the error notices are vague, and even gstreamer's own debugging tools are vague, when you manage to install them. Reinstalling doesn't work, almost always, because the problem is almost always with the system not finding the plugins path ( that's what the uridecode warning means ) but you don't know, there is no support, and the error warnings are vague and useless what's worse: they confuse. Usually the problem can be solved, since the 90's, just looking for the hidden folder

.cache/gstreamer-1.0 in the home folder

inside is a binary that contains the gstreamer path and settings. Just delete the binary, and restart any player that uses gstreamer, and it will create a new binary! That's what solved my problem... But it's not always like that, and that's where the real trouble comes: Instead of using a stable system of paths, gstreamer uses the system's paths, the right option to make the system vulnerable. As system paths are highly vulnerable to the environment, and the environment to Python ( another one that has path issues ) -- I've always advocated that Python should have fixed paths, defined by the system developer, without wanting to reinvent the wheel, and always I advocated that these paths should be SEPARATED from the environment's paths, and configured separately: even better: that the Python environment be separated from the rest of the environment, in a separate file, and that there would always be an option available to reset the python environment, without having to reset the entire environment. Because if the system path is corrupt -- usually because of some python install, like pip, and this is happening more and more often -- then all is lost. Gstreamer relying on this is therefore a bad decision. There was a time when the system path was something solid and stable, but that time is long gone! For security reasons, as python installations are an eternal source of problems. That's it.