https://bugs.kde.org/show_bug.cgi?id=317656
Filipus Klutiero <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.kde.org/show_b | |ug.cgi?id=282535 Status|REOPENED |CONFIRMED --- Comment #10 from Filipus Klutiero <[email protected]> --- I must confirm that this affects both Debian 9 and Kubuntu 19.04 (KOrganizer 5.10.3). However, when KOrganizer is shut down (or restarted), either this issue happens, or it does not happen. When it happens, all suspended reminders fail to display. When it does not happen, all suspended reminders do display. And in some cases, all fail to display, but display when KOrganizer is restarted again. Unfortunately, I have no idea when each case occurs. I tried with 1 or 2 suspended reminders, and it happened in both cases. I tried with suspended reminder postponed until a time before or after korgac's restart, and it happened in both cases. However, ticket #282535 documents that this was completely broken after the switch to Akonadi: https://bugs.kde.org/show_bug.cgi?id=282535 But the contributor who developed the fix was not familiar with Akonadi, and wasn't sure the fix would always work. korgac's communication with Akonadi appears to be quite a hack: // Check if Akonadi is already configured const QString akonadiConfigFile = Akonadi::ServerManager::serverConfigFilePath( Akonadi::ServerManager::ReadWrite); if (QFileInfo::exists(akonadiConfigFile)) { // Akonadi is configured, create ETM and friends, which will start Akonadi // if its not running yet setupAkonadi(); } else { // Akonadi has not been set up yet, wait for someone else to start it, // so that we don't unnecessarily slow session start up connect(Akonadi::ServerManager::self(), &Akonadi::ServerManager::stateChanged, this, [this](Akonadi::ServerManager::State state) { if (state == Akonadi::ServerManager::Running) { setupAkonadi(); } }); } There's also a doubtful if in KOAlarmClient::checkAlarms(): // We do not want to miss any reminders, so don't perform check unless // the collections are available and populated. if (!collectionsAvailable()) { qCDebug(KOALARMCLIENT_LOG) << "Collections are not available; aborting check."; return; } Unfortunately, I can't find what goes in KOALARMCLIENT_LOG on my session, so I can't use the logs to determine if that's the problem. -- You are receiving this mail because: You are the assignee for the bug.
