https://bugs.kde.org/show_bug.cgi?id=416139
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #6 from [email protected] --- Here's an update on multiple related issues around this error, and some findings that might help to locate and remove its causes. This has two parts: a technical, and a philosophical one. You may not like the 2nd part, but it may be the more important one. With kdenlive 20.xx and later (details see below), all as AppImage, the same error may occured on my system even *with* some pulseaudio packages at least installed (maybe not properly running though). It also happened when I used the asound wrapper. I found that it depends on the availability of a kdenliverc (or kdenlive-appimagerc) file, whether this contained a [sdl] with the line audiodrivername=alsa or audiodrivername=dsp as described below. The error always occured when that config file or this section+line were missing, or when that parameter hat a differnt value. The creation of such a config file with a suitable entry in [sdl] was the sole, immediate and perfectly reproducible way to convert a constantly crashing kdenlive 20.xx .. 21.12.2 back into a usable one. And the use of a value other than alsa or dsp, or the removal of the paramter [sdl] audiodrivername=..., or of the complete config file, was an immediate and perfectly reproducible way to make the error come back. -------------------------- Actual observations (and related errors actually leading to this one): On my system, after an attempted upgrade to kdenlive 22.x AppImage, this error dialog appeared: --- Unable to create KIO worker. Can not find a KIO worker for protocol 'tags'. [OK] --- This is probably a consequence of a separate bug or new, unknown and unmet dependency on my system (even when using an AppImage to avoid exactly such dependencies). Then it said in the konsole (terminal) log: --- ALSA lib /home/appimage/Craft/BC/linux-64-gcc/build/libs/libasound2/work/alsa-lib-1.2.5.1/src/conf.c:4499:(snd_config_update_r) Cannot access file /home/appimage/Craft/BC/linux-64-gcc/share/alsa/alsa.conf Speicherzugriffsfehler --- And crashed. On the next attempt to start kdenlive, this crash was noted and kdenlive suggested to delete (or reset) the config files - sadly, with the focus already on the "yes" / "ok" / "Zurücksetzen" button. This detail by itself is a very bad idea, and therefore a separate bug, because: After the missing config file(s), all tested kdenlive versions > 18.x (both AppImage and FlatPak) would now permanently crash forever, with these lines in the konsole output, and this different error dialog (=error 416139): --- Fehler - Kdenlive Video-Vorschau-Fenster kann nicht erstellt werden. Es stimmt etwas mit Ihrer Kdenlive-Installation oder den Treiber-Einstellungen nicht. Bitte beheben Sie dieses Problem. [OK] --- This error message is misleading, because it directs the user towards a video related problem. The actual cause is, however, audio related. Im quoting the German dialog here in addition to the English text from the original error, because I found this reported by multiple puzzled users in various forums without a definitve resolution or remedy. And it took myself a night to find a specific and reliable workaround: The user actually needs to PRODUCE a kdenlive-appimagerc (or, probably, kdenliverc for non-AppImage-Setups) which MUST have at least this section - and it is completely sufficient to have only a single line in this section: --- [sdl] audiodrivername=alsa --- or -- [sdl] audiodrivername=dsp --- Actually, I tried different entries for this parameter: The following ones, which kdenlive can write after selecting differnt options from its settings dialog, will make the program crash after applying the settings, or on the next restart: audiodrivername=pulseaudio audiodrivername=esd audiodrivername=artsc The same happens, when "Automatic" or "Automatisch" is selected in the dialog: That will produce an [sdl] section which has ONLY the (unrelated) line "blackmagic_output_device=-1", but NO entry for audiodrivername (=the same situation as without any kdenliverc or kdenlive-appimagerc file). And that will invariably cause a crash with the above error dialog on startup. Only the following entries will allow kdenlive to come up and work WITHOUT the above error dialog: audiodrivername=alsa audiodrivername=dsp When I manually put another illegal entry to that parameter (e.g. "oss", which is NOT valid, even thought the entry in the pull-down menu is "OSS"), then kdenlive will ALSO crash with the same error dialog. There might other entries in the other lines of the same section that might be able to cause the same crash (unsure, I don't want to review the notes from my testing any further). But the parameter and values noted above should be the central clue to find the cause of this error and remove it. Also noteworthy, related to the other error (noted at the beginning) which lead me into this one: Versions kdenlive-20.12.3a-x86_64.appimage, 21.04.2, 21.08.3a, 21.12.2 can run on my system when [sdl] audiodrivername=alsa or =dsp. 22Versions 21.12.3 and 22.xx always show the error message noted at the beginning of this report, and WITHOUT [sdl] audiodrivername=alsa or =dsp, they crash exactly like the older versions do (related to this error report) - and WITH [sdl] audiodrivername=alsa, they crash in their own way as described above (for which I haven't found any cure yet). This difference was introduced between 21.12.2 and 21.12.3. The only version available to me which is completely resilient and shows NONE of these errors is: kdenlive 18.12.3-1 (the last one included with Devuan beowulf, i.e. NOT and AppImage version, therefore using kdenliverc and not kdenlive-appimagerc). I hope that with this precise information, it should be feasible to locate the cause of these (multiple errors). ------ Some vague and adventurous speculations on the origin of these errors: As others have pointed into this direction, I'm afraid these errors might all be an offspring of some overly-optimistic (or: careless) introduction of dependencies on pulseaudio somewhere between versions 18.xx and 20.xx. And therefore, they're just another perfect example for how the (merely perceived?, or actively prepared?) urge to include pulseaudio, combined with a failure to ensure the continued usability of your product *without* pulseaudio, produces quite some propulsion (=free benefit) for pulseaudio - but at the same time, produces many cases of dissappointment or extreme fault isolation workloads (=disadvantage) for kdenlive users and developers. And this is just one more example for why I dislike pulseaudio, systemd, and their underlying marketing strategy: Both of these have caused applications that once worked very well without them - to now completely fail, whenever pulseaudio or systemd are missing (say, Devuan Linux or Mozilla Firefox - i.e. NO small victims). - Similar damage occurs even for AppImage based deployment here. This strategy also manifests itself when users who want to remove a simple unwanted sound server or init system - faces the package manager to removing large scale environmets like all of KDE, or even the ability to use a previously mainstream distribution, due to such intentionally promoted, but factually unnecessary dependencies. Or else: The user must accept a product he doesn't want, to use a product that he wants. For pulseaudio, in my own experience, this means more overhead, more audio latency, maybe audio data changes, complexity and constant uncertainty about what's actually happening in the audio system. Additionally complicated by "modern" widget "designs" (e.g. to define preferred audio devices) where you can't easily say whether some colour shade means that a given device is now activated or not. And even as a proficient computer user, even in a dedicated error isolation quest: Once again, I cannot tell whether pulseaudio does currently run (and run as intended), or whether there are merely some of its (unwanted, partly unavoidable) packages installed. In any case, it seems to be dysfunctional, for whatever reason I don't (even want to) understand. So, in my opinion TL; DR: Any hard dependency on pulseaudio is a bug exactly as severe as any hard dependency on systemd. I may be wrong (and misguided, because I don't want to spend more time on basic research after having spent unplanned 10+ hours on error isolation repeatedly) - but once again exemplified today, both of these products follow the same traits, and their names and effects repeatedly observed by myself have significantly contributed to bringing the all too well known "MS Windows user-experience" into the Linux world. Communications of their makers quoted by others have indicated this is intentional (=first, making promises and dependencies easy, then breaking products when users don't want to follow them). It's also classical Microsoft strategy (see: html vs. MS Windows Explorer, or MS Office Formats support etc.) So developers of actually useful software might be very well adviced to keep their own products working both with, and, much more importantly, without such not-so-healthy dependencies. But well, whatdoyaknow, and what do I know... -- You are receiving this mail because: You are watching all bug changes.
