Dear Maintainer,

   * What led up to the situation?
Last week (approx 2025-01-06) I updated Debian testing with all the new
akonadi, korganizer and kdepim6 packages.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
Just updated, then rebooted (multiple times).

   * What was the outcome of this action?
After the updated was applied, you can see Korganizer has changed a bit, for
instance the task description are now hidden by the endDate time, while before
you could read the task description (but that's for another bug report).
However the BIG problem here is that every single action in korganizer (not in
kmail) takes between 4 to 10 seconds to execute.
You want to use the mousewheel on the mini-calendar view to switch weeks ; 10
seconds wait time for _each_ week.
You want to edit a tasks by double-cliking it; 5 seconds of wait time. Wait,
there's more; once the task editor opens, you again have 3-4 seconds of wait
time before being able to edit it's description.
You want to move a task to another day/time, 5 seconds.
You want to create an event, 5 seconds.
You get the gist; it has become _unusable_; how could that pass for unstable to
testing, not sure.

   * What outcome did you expect instead?
Each of the actions described above should be instant, like it has always been
for the last 20 years.


Please revert any patch applied during the last (two?) week so that it's usable
again.

Thanks for your time and work

Hej,

Am Montag, 13. Januar 2025, 23:50:06 MEZ schrieb Alexandre Bonneau:

I can absolutely not reproduce your observations. korganizer is as fast
as ever for those actions you described for me. I suspect it's either
something in your akonadi database or maybe some old config causing
trouble.

Which database type are you using ?
Which calendar type are you using ?

What you can do is create a new user on your system and see if you can
observe a similar behaviour.

And no, reverting the update to 24.12 is not an option.

	Hello Patrick,

Well, that's unfortunate.
» dlg akonadi
rc  akonadi-backend-mysql    4:22.12.2-1
ii  akonadi-backend-sqlite      4:24.12.0-2

I'm not sure why the migration to 24.12 used sqlite instead of mysql. Could that explain the
extremely slow response time in Korganizer?
I'm using akonadi_davgroupware_resource_1 for a nextcloud-synchronized calendar.

I'll try to install akonadi-backend-mysql 24.12 and see if that fixes anything

I installed the latest version of the mysql backend, however I was puzzled by the fact that
you could install different backend at the same time.
I thought that it would convert from one database to the other during the installation
process, but no.
I searched how to migrate from sqlite to mysql (I do not remember doing the mysql to
sqlite migration in the first place), and stumbled upon https://dev.gnupg.org/T6862[1].

It looks like the existing akonadi migration is pretty useless and requires lots of manual
work, and in the end is just not robust enough.

I'd prefer having a solution for the current sqlite backend I use, because Korganizer is, as
stated before, unusable in this state.
Could I record some logs to see where the slowness comes from?

Regards,
Alexandre Bonneau

Le lundi 13 janvier 2025, 15:46:51 UTC−10:00 Alexandre Bonneau a écrit :

--------
[1] https://dev.gnupg.org/T6862

I created a new user, and launched Korganizer :
- With no other agenda than the default one, everything is responsive as usual
- When creating a calDav agenda (Nextcloud), the sync is pretty quick for a 4
year history with 9900+ elements
- However, when trying to switch weeks, the slowness is there, which makes
korganizer unusable

- I tried deactivating the nextcloud calendar to see if the responsiveness
came back, but that made korganizer crash.
- After relaunching korganizer, I could deactivate the nextcloud calendar, and
then the app was responsive again to change weeks with the mouse wheel

- I deleted the user and tried again with only a 3 year history (~4600
elements), but the slowness was the same.

- Then I deactivated the nextcloud calendar, created a new local calendar from
an old backup (from 2021), which contained 21600+ elements according to
akonadi console. The slowness returned immediately.


So, it looks to me that the korganizer update borked something, not
specifically related to remote calendars, but more about how it manages to
query the elements it needs to show.
However I could not feel a big difference with the seconds needed to display a
week with 100+ elements (tasks and events), or a week with only 15 elements.

I'm not sure the Korganizer are dog fooding the app with that much history and
elements, perhaps that would explain why it was not caught during development;
if needed, I could send a calendar.ics file for further testing (provided there
is a way to anonymise the description, place, summary, participants, and any
other personal info).


Side note; on the new user, the tasks description were correctly displayed
without the endDate time taking the whole space. So I changed the global 125%
resolution I had on this user, and switched it back to 100%, then adjusted the
font size; now the tasks descriptions are displayed like 2 weeks ago, without
the enddate time in the way.

Hey,

The backend packages  only exist, because it is impossible to express complex
dependencies within one package. So those -backend- packages just install the
needed packages to use this backend.

In akonadiserver we switched the ordering, to prefer sqlite over mysql for new
installations, but for an upgrade apt shouldn't switch the backend packages.
Aka apt should prefer upgrading the mysql backend  over remove mysql  &
install sqlite. How did you do your updates?

To see what backend you are using you have to look into
 ~/.config/akonadi/akonadiserverrc
under [%General] you find the used backend.

Regards,

hefee

	Hello Hefee,

It's weird because in the ~/.config/akonadi/akonadiserverrc file, I can see:
```
[Debug]
Tracer=null

[%General]
Driver=QMYSQL

[QMYSQL]
DataDir=/home/myuser/.local/share/akonadi/db_data
Host=
Name=akonadi
Options="UNIX_SOCKET=/run/user/1000/akonadi/mysql.socket"
ServerPath=/usr/sbin/mysqld
StartServer=true
```
...which is coherent with the fact that I upgraded from previous Debian version the usual
way (changing the repo in source.list, the apt update && apt dist-upgrade).
However my akonadi-backend-mysql package was in `rc` mode, so how could that work
until now ?
As stated before, I've (re-)installed akonadi-backend-mysql for now.

Regards,
Alexandre Bonneau

Le lundi 13 janvier 2025, 22:23:49 UTC−10:00 Hefee a écrit :

Hey,

Okay somehow apt decided not to upgrade but prefer to remove and install...
That is not great.
work until now ? As stated before, I've (re-)installed akonadi-backend-mysql
for now.

As I said the backend packages only makes sure, that you have mariadb-server-
core, mariadb-client and libqt6sql6-mysql installed. But you can install those
also by hand and use the backend successfully. The backend packages should
make it easier for a user to not search for those dependencies.

Regards,

hefee

I’m a little puzzled that you have 22.x for mysql and 24.x for sqlite.
Testing currently has 24.x for both of them.

Although this doesn’t directly address your particular bug, which appears to
maybe be something that happens with large amounts of calendar entries, you
might be interested in the discussion about how much faster sqlite runs
compared to postgresql (and possibly mariadb).

https://lists.debian.org/debian-kde/2024/12/msg00079.html

That sqlite3 metric is interesting indeed.

However even after the few upgrades to kdepim and korganizer since I opened this bug,
hoping they would fix this critical problem, the problem is still present:
korganizer 4:24.12.2-1
kdepim 4:24.12.2+5.158
kdepimruntime 4:24.12.2-1
akonadiserver 4:24.12.2-1

As a sidenote I upgraded my computer to a Ryzen 9 X3D, and I can noticeably see that
when moving tasks or events around, it takes a few seconds less.
Everything seems to point to the fact that this slow response time is CPU-bound.

Not sure if this is related, but that bad Korganizer upgrade also broke at least 2 things:
- When using tags with accents in it, Korganizer mangle it so that for instance "é" appears
as "é", creating new faulty tags in the tags list.
- Sometimes when you edit a calendar task or event, the tags are just plain removed (even
if they do not contains any accent), which updates the events on Nextcloud, which are
replicated without any tags on the correct Korganizer clients (from Debian stable).

This is especially annoying on past meetings with other people where if you want to 'fix'
the missing tag, you need to edit the event..which will send the 'update' to every
attendees. Not possible in a work environement.

To sum up, before having 10k+ event was not a problem, now it is. Where do we go from
here?

Regards,
Alexandre Bonneau

Le mardi 14 janvier 2025, 10:17:12 heure de Tahiti Soren Stoutner a écrit :

Hi,

On Mon, 24 Mar 2025 16:26:41 -1000 Alexandre Bonneau  <alexandre.bonneau@linuxfr.eu> wrote:
[...]

I don't really know how to debug this. The only thing I can recommend is
to file a bug upstream. They should be able to debug it.

	Hi,

I declared the bug upstream there: https://bugs.kde.org/show_bug.cgi?id=501965[1]
Since this makes Korganizer unusable, but there has been not much activity for a month, I
fear the fix will not come soon..

Regards,
Alexandre Bonneau

Le dimanche 4 mai 2025, 00:34:44 Patrick Franz a écrit :

--------
[1] https://bugs.kde.org/show_bug.cgi?id=501965