Created attachment 176747 [details] quick search SUMMARY After upgrade to kmail2 6.3.0/akonadi 24.12.0, mail search as well as quick filter via search line doesn't work as expected. Either the result set is empty or a subset is found, only. This fails for inboxes on a local cyrus imap server, gmail accounts, remote imap servers (ionos.de) and local folders. DETAILED DESCRIPTION In order to avoid interferences with fetching, I waited until kmail2 finished synchronizing mails from all servers. Then I opened my primary mailbox, and entered some quick search text without any further search restrictions. Got no results. Then I tried the mail search dialog, but no matter, what I entered, I got no results, where I knew, there are mails, that match. At this point, I started akonadiconsole, removed the akonadi cache on my INBOX, restarted akonadi, and then kmail. Still no results. After that, I was quite puzzled. After further tests, I can conclude, that apart from searching, everything else is working as expected. Digging deeper into the issue, I discovered this: On the maintenance tab of the folder properties of my INBOX, there's a checkbox for fulltext indexing, which is checked of course, but the indexed count differs significantly from the number of items in the folder: 4873 vs. 58275. Consequently, some mails are found now, if I enter a search, that is covered by the indexed subset. Pushing the <Index folder again> button, the indexed count displays the same number of indexed items again after reopening the properties dialog box. Well, that is explainable, then. If only a subset of items is indexed, the result set is a subset as well. But things get stranger in other folders. Here INBOX/Sent. Here the item numbers match after deleting the akonadi cache and pushing the <Index folder again> button. But still, the quick search finds a subset only. Will attach screenshots. Here, the "find messages" dialog finds all expected messages. Just displaying them in the "Last search" folder fails (empty). OTOH, the "find messages" dialog in INBOX without recursion finds all items, that are displayed in the quick search list. Again, a subset of all possible matches. I searched for a certain sender address, and checked by sorting the list by sender. BTW: a notable fact from my setup: the akonadi db is hosted on a local postgres 17 database. The question is: why aren't all messages indexed, and why does the quick search displays a subset only at times... SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20241216 KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.11.7-6-preempt (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor Memory: 62.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060/PCIe/SSE2 Manufacturer: ASUS
Created attachment 176748 [details] vs. search dialog
This hasn't changed in version 6.3.1 (24.12.1). All those bells and whistles in Kmail are worth nothing if searching is not reliable. Reliable search is the most important function in a mail client (apart from getting mail in the first place)! Please help someone...
Same issue with a dovecot IMAP server.
Adding a me too: this happens with several POP3 accounts (so, local emails), akonadi on sqlite. I see a lot of errors like "org.kde.pim.akonadi_indexer_agent: Xapian error in indexer 0x7fba90010280 : Expected block 1932 to be level 0, not 2" after restarting akonadi, even after I emptied its databases trying to reindex my emails, which fails or doesn't index all of them. Versions: kmail2 6.3.3 (24.12.3) Operating System: Fedora Linux 42 KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.13.0 Qt Version: 6.8.2 Kernel Version: 6.14.2-300.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i5-1035G1 CPU @ 1.00GHz Memory: 15.2 GiB of RAM Graphics Processor: Intel® UHD Graphics
Similiar/same issue with all kind of kmail email searches only (local folders, IMAP) in the fast search as in the full search function. I did not get any results anymore. while other searches in kontact (i.e. addressbook) as in the KDE environment (filesystem) seems to work well. KDE 25.04.0 kmail 25.04.0 kontact 25.04.0 akonadi 25.04.0 baloo 6.13.0 Gentoo Linux current thx, niels.
Want to raise this as well... the search only shows results from about one week. It used to be able to search through all my messages. I've turned on 'download for offline use'. What did seem to help/improve was clicking "Re-index folder" in the Folder Properties under Maintenance. Before it was showing ~170 items, after indexing it's showing ~6500 which is a big difference. Maybe it's just an issue with indexing? SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20250611 KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.1 Graphics: X11 kmail-25.04.2 akonadi-25.04.2
Same here, it works in one inbox, with another typing to search box it just clears the message list. I've done the Download all and reindex as well, no help.
I had a very similar problem. The main problem is that the akonadi server doesn't report the path to the database with problems. This is how I solved it - Stop akonadi for example: akonadictl stop akonadictl status - Stop baloo for example: ps -ef | grep -i balo xxx 7653 3297 0 08:54 ? 00:00:00 /usr/libexec/baloorunner kill -9 7653 ps -ef | grep -i balo - Removes the akonadi and baloo search databases ~/.local/share/akonadi/search_db/ ~/.local/share/baloo/ - Restart akonadi and baloo (preferably a system reboot) - Force rebuilding the indexing For example, from the akonadi console Find and select the indexing agent Put it offline Put it online WARNING, This procedure should only affect indexing, but there's always a risk of data loss, you should have a backup and know how to restore it.
Just came here to say that I have exactly the same problem... (On a fresh Debian Trixie install with KMail 6.3.3.)
Looks, like 6.5.2 works well again...
(In reply to Hans-Peter Jansen from comment #10) > Looks, like 6.5.2 works well again... Not here, typing to search box makes message list completely empty. KMail 6.5.2 and Pgsql Akonadi on Fedora.
(In reply to Juha Tuomala from comment #11) > (In reply to Hans-Peter Jansen from comment #10) > > Looks, like 6.5.2 works well again... > > Not here, typing to search box makes message list completely empty. KMail > 6.5.2 and Pgsql Akonadi on Fedora. Which PostgreSQL version is installed on your system?
..and what's the result of: `akonadictl status` on your system?
(In reply to Hans-Peter Jansen from comment #13) > ..and what's the result of: > > `akonadictl status` > > on your system? @Hans-Peter Jansen What's your PostgreSQL version? PostgreSQL 18 is currently causing problems under Arch Linux.
(In reply to sourcemaker from comment #14) > (In reply to Hans-Peter Jansen from comment #13) > > ..and what's the result of: > > > > `akonadictl status` > > > > on your system? > > @Hans-Peter Jansen > What's your PostgreSQL version? I'm using 18 here on my Tumbleweed desktop, just for akonadi. > PostgreSQL 18 is currently causing problems under Arch Linux. Define problems.
(In reply to Hans-Peter Jansen from comment #15) > (In reply to sourcemaker from comment #14) > > (In reply to Hans-Peter Jansen from comment #13) > > > ..and what's the result of: > > > > > > `akonadictl status` > > > > > > on your system? > > > > @Hans-Peter Jansen > > What's your PostgreSQL version? > > I'm using 18 here on my Tumbleweed desktop, just for akonadi. > > > PostgreSQL 18 is currently causing problems under Arch Linux. > > Define problems. https://bugs.kde.org/show_bug.cgi?id=511650 All calendar tags were changed for no reason and automatically updated to the radicale server. For example: Rückfahrt is now updated to Rückfahrt (return trip) Also, the akonadi_migration_agent starts on every login. PIM Maintenance (Finished)
Arch Linux with Akonadi version 6.5.3 (25.08.3) and a system-wide PostgreSQL 18 instance. I used PGTune to optimize the PostgreSQL instance: max_connections = 200 shared_buffers = 1GB effective_cache_size = 4GB maintenance_work_mem = 1GB checkpoint_completion_target = 0.9 wal_buffers = 16MB default_statistics_target = 100 random_page_cost = 1.1 effective_io_concurrency = 200 work_mem = 4283kB huge_pages = off min_wal_size = 100MB max_wal_size = 2GB max_worker_processes = 4 max_parallel_workers_per_gather = 2 max_parallel_workers = 4 max_parallel_maintenance_workers = 2 wal_level = minimal max_wal_senders = 0