Interface crashes
-
It's only fair to start by congratulating the developers not only on their good work, but also on the right development decisions. As a linux mint tester, I've been grappling with the stupid decisions of canonical, python.org and gstreamer.org. I breathe a sigh of relief when I see a quality fork, where they seek to improve the original work, and not reinvent the wheel.
Note I migrated from Clementine to Strawberry after Clementine's unsolvable problems with Gstreamer where it won't start because it can't find the uridecode path. A problem that is known to be unsolvable from the Gstreamer side, that is, the user cannot do anything.
But going to the subject that brought me here, I have faced in 1.0.17 an interface crash, every time I rewrite the playlist ( .xspf -- I stopped using .m3u after constant errors loading the list in that format; but I haven't tested it yet in Strawberry ) But the problem here is not with reading or with the file format of the playlist, but rather the guaranteed crash of the interface every time I save the list in /run/user/1000/doc, and only in that path. Saving the list in any other folder is fine, but Strawberry doesn't follow the list saved in places other than /run/user/1000/doc, which I personally think is an error, but I don't discuss development decisions when something it works. The crash is such, the interface freezes, and I need to kill the process and restart to resume the interface's responsiveness. Is there anything I can do about it, like changing the list save location, or maybe changing the path? -
I found where the bug was. But the solution proved to be only temporary. My distribution, Linux Mint already has the path /run/user/1000 created by default, with system-only permissions. The Strawberry Player installation can create the doc file ( /run/user/1000/doc ) on it during installation, but it cannot change permissions, nor does it allow a locally installed application to create new folders in /run/user/1000. Soon, I had to change the path permissions, but when testing, strawberry changed the path to /run/user/1000/doc/6995cbb2. Well, I just added a 6995cbb2 folder, which Strawberry couldn't create, and put the .xspf playlist file inside it, and I was able to save a new playlist without crashing the player. But the files in that path appear to be temporary; and after restarting the machine, they are erased and recreated, minus the 6995cbb2 of course. That is, every time I restart the machine, I lose all work.
I will need a better solution.
-
Everything indicates that the user directory of /run/user/1000 in Mint is a virtual file system, running in tmpfs in RAM.
-
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 folderinside 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.