Since a recent update (last week, I do not know the exact date) amarok no longer starts on my machine.
Running amarok from the command line results in this output:
**********************************************************************************************
** AMAROK WAS STARTED IN NORMAL MODE. IF YOU WANT TO SEE DEBUGGING INFORMATION, PLEASE USE: **
** amarok --debug **
**********************************************************************************************
Got ERROR: "Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist" errno: 2000
QObject::connect(Playlist::Model, Playlist::ProxyBase): invalid nullptr parameter
QObject::connect(Playlist::Model, Playlist::ProxyBase): invalid nullptr parameter
QObject::connect(Playlist::Model, Playlist::ProxyBase): invalid nullptr parameter
QObject::connect(Playlist::Model, Playlist::ProxyBase): invalid nullptr parameter
Attempted to overwrite a QRandomGenerator to system() or global().
20 -- exe=/usr/bin/amarok
17 -- platform=wayland
15 -- appname=amarok
17 -- apppath=/usr/bin
9 -- signal=6
9 -- pid=9003
18 -- appversion=2.9.71
19 -- programname=Amarok
31 -- bugaddress=submit@bugs.kde.org
KCrash: Application 'amarok' crashing...
The Wayland connection experienced a fatal error: Bad file descriptor
When running amarok --debug this is the end of the output:
(I would attach the whole output as a file, but the forum doesn’t let me yet.)
Why am I opening this topic here?
Looking at bugs.kde.org, there are still new reports created for amarok, none of which seem to be containing this issue. For this reason I think this might be related to Tumbleweed (or my configuration of it, though I can’t think of what I could have changed that would touch these things…).
Searching for “overwrite a QRandomGenerator to system() or global()” did not yield many results, and none that looked applicable to me.
Versions amarok 2.9.71, 2.9.75git.20230322T021226~4f7c3aff99-1.1-x86_64 from vendor openSUSE
QT Version: 5.15.8, 5.15.8+kde183-1.1-x86_64 from vendor openSUSE (ibQt5Core5)
I would appreciate any suggestions as to what to try and be happy to provide further information.
I’m sorry, I won’t be able to help a lot except for this one:
You can use susepaste. Just copy the output there and post the link here. It’s not actually a file but you can add much longer output than in the forum. It’s also available as shell command. Try man susepaste to check it out.
Hm, I still don’t think I can help a lot. I’m not on Tumbleweed nor Wayland, rather Leap and X. But at least a there’s a little. First, I thought this could be the culprit:
But no. I have the same line here and Amarok doesn’t seem to care. It’s running fine. Maybe rather this one:
Asking the Duck gives a lot of replies, neither seems to be related to Amarok, rather Wayland which I don’t know at all. But I don’t think switching to X would be a proper suggestion.
Switching back to X would be a price to high to pay for a working amarok at this point, so I tried forcing amarok to run through XWayland. That did not make a difference.
Defeated, I also started up an X Session and tried it there. It still doesn’t work. Interestingly, after the system tries to start drkonqi a number of pa_write() failed while trying to wake up the mainloop: Bad file descriptor lines appear.
This is then followed by much delayed blocks like this: QSocketNotifier: Invalid socket 5 and type 'Read', disabling... QSocketNotifier: Invalid socket 9 and type 'Read', disabling... QSocketNotifier: Invalid socket 14 and type 'Read', disabling... QSocketNotifier: Invalid socket 74 and type 'Read', disabling... Unable to start Dr. Konqi Re-raising signal for core dump handling.
Here too, the output is abruptly interrupted by the QRandomGenerator thing.
First, I thought this could be the culprit:
I actually was fooled by this as well and discovered, that my mysql/mariadb appears to be brroken beyond what I can repair with my little knowledge and the hints various commands throw me. And besides, Amarok allows you to use an external DB, so I’d imagine that it has a nicer way of handling faulty DBs than just refusing to start.
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Problem: nichts stellt 'nss' bereit, das vom installierten mattermost-desktop-5.2.2-26058.x86_64 benötigt wird
Lösung 1: Deinstallation von mattermost-desktop-5.2.2-26058.x86_64
Lösung 2: mattermost-desktop-5.2.2-26058.x86_64 durch Ignorieren einiger Abhängigkeiten brechen
Wählen Sie aus den obigen Lösungen mittels Nummer oder brechen Sie (a)b [1/2/a/d/?] (a): 2
Abhängigkeiten werden aufgelöst...
Die Abhängigkeiten aller installierten Pakete sind berücksichtigt.
(German, mattermost-desktop is missing a requirement, but working fine, the rest seems to be ok.)
Using zypper pa -iR I can’t immediately find any qt related packages (expect for multiple vlc-qts) that don’t come from official looking repositiories.
(I cannot attach the output here, as it is too large, even for openSUSE paste)
You are aware that removing a repository does not remove/change any package installed from that repository.
In order to fix your videolan/packman mix (after removing the videolan repository) you would need to run
zypper dup --allow-vendor-change
but this might give you troubles with packages installed from any of the other non-Tumbleweed repositories.
To avoid this you should
Disable all repositories except oss, non-oss (and update).
Run zypper dup --allow-vendor-change
This should give you a pure Tumbleweed system (plus a lot of packages that may or may not work)
Enable the packman repository.
Run zypper dup --allow-vendor-change --from packman
This should give you a system with non-free multimedia working.
Enable the other repositories one by one and install the packages you need (Actually I do not recommend this step. It will install software which is not tested and which may replace system packages. Only do this if you absolutely understand what happens.)
I did not see that this too is factory related. Removing it and doing a zypper dup --allow-vendor-change changes a lot of packages over to open suse. After a reboot the issue with amarok not starting still persists.
This one is for the maliit framework and maliit keyboard. As far as I can tell the only on screen keyboard that works on wayland. (Please correct me on that, I would love an alternative.)
Yes, this provides signal-desktop, which I require to communicate with, among others, my family living half of europe away from me. I might look into replacing this with a flatpak/snap though.
I actually use --allow-vendor-change quite frequently. With the number of repositories I have/had this became somewhat necessary, but probably also quite risky. After removing all the videolan repos (which never actually gave me trouble), the factory stuff and some others I did not experience any issues running --allow-vendor-change.
I guess I should still try step one and two anyways to see if at that point I can at least start amarok again.
Thank you all for the help and patience.
(Side note: all of the repositories I added did at some point serve a purpose, like gaining access to an up-to-date discord, signal, maliit-keyboard etc. I will use this as a nudge to clean up more frequently.)
TL;DR: The issue is with the Random Track Progression feature of amarok (Hence QRandom). This being enabled is stored in the config, meaning it gets loaded as soon as you start amarok.
Thank you for the suggestion, but even with this I still get the same error.
Now the only packages that are not from Main Repository (OSS) or Main Repository (NON-OSS) are marked as @System: https://paste.opensuse.org/pastes/c88f69764a9c (66 in total). zypper verify still only complains about mattermost-desktop.
Following step 3 and 4 (reenabling packman) also does not help.
(I should add that throughout all of this I rebooted after every zypper dup --allow-vendor-change, just to be sure that everything is up to date.)
I suppose that I can say with some confidence, that my package situation is not the culprit here.
While typing this I thought about what else might be causing the issue. Some configuration came to mind. I went to look at the amarok configuration file and discovered that next to amarokrc there was an amarokrc.MNwUDu in ~/.config. Deleting both of those resulted in amarok starting again.
Some more experimentation reveals that setting the playback to random order (in the bottom right, Track progression → Random Tracks) causes amarok to immediately crash. As I typically use random track progression amarok stored this in it’s configuration, which was last edited on 2023-03-28T19:02:00Z. After that some update must have broken this feature.
You can try using Random Track Progression, but I would recommend making a backup of your `~/.config/amarokrc, even though amarok crashes before being able to overwrite the config.
Thank you all for your efforts. I suppose I will open a bug on the kde bug tracker after all.