If you pin Elisa to Task Manager then click on it for first time it will launch Elisa, but when you close it (the process correctly disappears from system monitor) then click on that same pinned icon for second time, it fails to launch the app and shows an error notification: Launching Elisa (Failed) Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.9.3-1-MANJARO (64-bit) Graphics Platform: Wayland
Is this with a kdesrc-build (or similar)?
(In reply to Harald Sitter from comment #1) > Is this with a kdesrc-build (or similar)? I didn't build it, it's installed as a regular package from Manjaro/Arch repos.
*** Bug 487971 has been marked as a duplicate of this bug. ***
I've looked at this on endeavour and I'm not convinced we are at fault here. What appears to happen is that systemd (and presumably by extension dbus-broker) thinks the dbus service for elisa is already running and then doesn't start it. Except obviously it is isn't running anymore so the activation health check times out on our end. Why systemd and the broker get confused isn't obvious to me though.
Hi there, I have this exact problem, after upgrading 'elisa-24.02.2-1' to 'elisa-24.05.0-1'. If I downgrade the package it works just fine. Elisa does start from the task manager (pinned) for the first time, but not thereafter. Running it from the terminal, or the application-launcher works just fine. I am not the best at this stuff, but journalctl gave me just this (after pinning elisa to the task manager and launching): >Jun 05 06:39:55 coffee-arch kded6[980]: Registering ":1.96/StatusNotifierItem" to system tray >Jun 05 06:39:57 coffee-arch kded6[980]: Service ":1.96" unregistered >Jun 05 06:39:57 coffee-arch systemd[804]: dbus-:1.2-org.kde.elisa@0.service: Consumed 2.183s CPU time. >Jun 05 06:39:58 coffee-arch plasmashell[1014]: error creating screencast "Could not find window id 0" >Jun 05 06:40:01 coffee-arch plasmashell[1014]: error creating screencast "Could not find window id 0" >Jun 05 06:40:39 coffee-arch plasmashell[1014]: error creating screencast "Could not find window id 0" This comes up, when successfully starting it from the application-launcher: >Jun 05 06:40:44 coffee-arch systemd[804]: Started Elisa - Music Player. >Jun 05 06:40:44 coffee-arch elisa[7494]: org.kde.elisa.indexers.manager: Local file system indexer is inactive >Jun 05 06:40:44 coffee-arch elisa[7494]: Unsupported option 'foreign_keys = ON' >Jun 05 06:40:44 coffee-arch elisa[7494]: Unsupported option 'locking_mode = EXCLUSIVE' >Jun 05 06:40:44 coffee-arch elisa[7494]: org.kde.elisa.indexers.manager: Local file system indexer is active >Jun 05 06:40:44 coffee-arch elisa[7494]: org.kde.elisa.indexers.manager: trigger init of local file indexer >Jun 05 06:40:46 coffee-arch wireplumber[925]: wp-event-dispatcher: <WpAsyncEventHook:0x5c6a425921b0> failed: failed to activate item: >Object activation aborted: proxy destroyed >Jun 05 06:40:46 coffee-arch wireplumber[925]: wp-event-dispatcher: <WpAsyncEventHook:0x5c6a42599690> failed: ><WpSiStandardLink:0x5c6a427e2b40> link failed: 1 of 1 PipeWire links failed to activate I looked at dbus-monitor while opening elisa from task manager and from app launcher, and I do not understand much of it, but the main difference was, that almost all arrays/dict entries were empty, whereas the messages were way longer when starting from app launcher. No obvious error messages that weren't also in the app launcher log. Maybe that could help someone. Operating System: Arch Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.9.3-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060 Ti/PCIe/SSE2 Manufacturer: ASUS
(In reply to Marc from comment #5) > or the application-launcher works just fine. Now that is interesting. Looks like the app launcher does not use dbus invocation to start the application. At face value that seems like a bug
Yes, it shows up as >dbus-:1.2-org.kde.elisa@0.service under applications in system monitor when launched from the task manager. And launched from the app launcher it shows as >Elisa same behavior with both '24.02.2-1' and '24.05.0-1'. But I discovered: You can launch multiple instances of 'elisa-24.05.0-1' when launched from the app launcher. You can't do this with the older version. I looked through the source code of both versions with meld (but I am no programmer, I must admit, so yeah) and I found some new code for 'KDbusService' in 'elisaapplication.cpp', seems to be one of the biggest changes between versions, could this be part of the problem?
I confirm, downgrading to 24.02.2-1 seems to be working fine.
I can confirm as well, downgrading fixes this issue :)
*** Bug 488157 has been marked as a duplicate of this bug. ***
May have been caused by https://invent.kde.org/multimedia/elisa/-/merge_requests/562; posted a comment there.
A possibly relevant merge request was started @ https://invent.kde.org/multimedia/elisa/-/merge_requests/587
Git commit d8bd1a35a835d44d28a07e7e671e7cfc29d07073 by Jack Hill. Committed on 07/06/2024 at 19:53. Pushed by jackh into branch 'master'. Fix DBus service activation Previously this was supposed to be started in ElisaApplication::create, except it wasn't started because this function was never called. https://doc.qt.io/qt-6/qqmlengine.html#QML_SINGLETON > By default, each QQmlEngine will try to create a singleton instance > using either the type's default constructor or a static factory > function of the signature T *create(QQmlEngine *, QJSEngine *) when > the type is first accessed. If both do exist and are accessible, the > default constructor is preferred. Test-plan: Run kdesrc-build --run elisa. After the window is launched, run the same command in a separate terminal session. Before: two instances of Elisa opened Now: only one instance of Elisa opens. Amends fc374017 M +0 -23 src/elisaapplication.cpp M +0 -2 src/elisaapplication.h M +15 -1 src/main.cpp https://invent.kde.org/multimedia/elisa/-/commit/d8bd1a35a835d44d28a07e7e671e7cfc29d07073
Thanks for your work! I built elisa from source (now version 24.0.7.70). I uninstalled the pacman version made an menu entry in the app launcher and pinned the kdesrc-build to my task manager and it seems to work as it should. I can now close and relaunch it from there.
Git commit ec8ae492467320e6cb09b88167d220493dba9479 by Jack Hill. Committed on 08/06/2024 at 11:10. Pushed by ngraham into branch 'release/24.05'. Fix DBus service activation Previously this was supposed to be started in ElisaApplication::create, except it wasn't started because this function was never called. https://doc.qt.io/qt-6/qqmlengine.html#QML_SINGLETON > By default, each QQmlEngine will try to create a singleton instance > using either the type's default constructor or a static factory > function of the signature T *create(QQmlEngine *, QJSEngine *) when > the type is first accessed. If both do exist and are accessible, the > default constructor is preferred. Test-plan: Run kdesrc-build --run elisa. After the window is launched, run the same command in a separate terminal session. Before: two instances of Elisa opened Now: only one instance of Elisa opens. Amends fc374017 (cherry picked from commit d8bd1a35a835d44d28a07e7e671e7cfc29d07073) M +0 -23 src/elisaapplication.cpp M +0 -2 src/elisaapplication.h M +15 -1 src/main.cpp https://invent.kde.org/multimedia/elisa/-/commit/ec8ae492467320e6cb09b88167d220493dba9479