[kontact] [Bug 334314] New: summary shows wrong day if you use another time zone
https://bugs.kde.org/show_bug.cgi?id=334314 Bug ID: 334314 Summary: summary shows wrong day if you use another time zone Classification: Unclassified Product: kontact Version: 4.11.5 Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: summary Assignee: kdepim-bugs@kde.org Reporter: h6zb8-kdebugs20120...@yahoo.de When a apointment has a different time zone as you live in, summary shows the wrong day if the time is at another day. Example: Appointment is set to 4.5.2014 22:00 UTC - 4 and your local time is UTC. Then the correct date to show for you localy would be 5.5.2014 02:00. But summary shows 4.5.2014 02:00 Reproducible: Always Steps to Reproduce: 1. set an appointment at next day, 23:00. Time Zone - 2 hours your local time (that means the appointment occure on the day AFTER tomorrow at 01:00 o’clock.). 2. check at Kontact’s summary 3. summary will show the wrong day Actual Results: Kontact summary shows the wrong day Expected Results: Kontact summary should show the right day -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 331156] Display of HTML-Message extremely slow
https://bugs.kde.org/show_bug.cgi?id=331156 --- Comment #21 from Orion orion200...@yahoo.co.uk --- I have never used the AdBlock function either so that is not what is causing the performance problem. It is quite clear that it is related to totally html mail e.g newsletters -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334280] IMAP Synchronisation with GMAIL takes 13 minutes to complete !!
https://bugs.kde.org/show_bug.cgi?id=334280 Christian Mollekopf mollek...@kolabsys.com changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED CC||mollek...@kolabsys.com Ever confirmed|0 |1 --- Comment #3 from Christian Mollekopf mollek...@kolabsys.com --- The problem with gmail is that it's CONDSTORE support is broken (I think it was something with the tag folders?), and we therefore have to fetch all flags on every sync. I think the resource simply ignored flag changes previously if there were no new messages. I can readd a similar workaround if CONDSTORE is not available (or broken as on GMAIL). Sorry if I introduced performance problems, but I'm generally preferring correctness over performance, but we can re-add optimizations as necessary. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334318] New: on adding old mail archive mixedmaildir resource consumes tons of memory
https://bugs.kde.org/show_bug.cgi?id=334318 Bug ID: 334318 Summary: on adding old mail archive mixedmaildir resource consumes tons of memory Classification: Unclassified Product: Akonadi Version: GIT (master) Platform: Debian unstable OS: Linux Status: UNCONFIRMED Severity: grave Priority: NOR Component: Mixed Maildir resource Assignee: kdepim-bugs@kde.org Reporter: mar...@lichtvoll.de CC: kram...@kde.org On looking whether mixedmaildir resource needs a similar fix as in Bug #334206 - While maildir resources synchronizes a folder KMail blocks on switching to a different folder I thought I try to through my old mixedmaildir archive into Akonadi. During KMail 1 times I used mbox folders to archive mails from maildir folders at the time when KMail 1 became to slow with large folders (i.e. about 2-4 mails in one folder was the usability limit back then on my old laptop). Well I did and on trying mixedmailresource consumed memory until the Linux kernel OOM killed it. Reproducible: Always Steps to Reproduce: 1. Have a large mixedmail folder. 2. Add a mixed maildir resource in Akonadiconsole and point it to that folder 3. Watch machine becomes sluggish until OOM killer steps in. Actual Results: 6.1 GB Resident Set usage on a 8 GB machine. PID TIDMINFLT MAJFLTVSTEXT VSLIBS VDATA VSTACK VSIZE RSIZEVGROW RGROW SWAPSZRUID EUID MEM CMD1/7 6132 -142595 41 328K 77724K 6.3G 136K 6.6G 5.4G 556.1M95936K 903.6Mmartin martin 71% akonadi_mixedm PID TIDMINFLT MAJFLTVSTEXT VSLIBS VDATA VSTACK VSIZE RSIZEVGROW RGROW SWAPSZRUID EUID MEM CMD1/7 6222 -140411 20 328K 77064K 6.5G 136K 6.8G 6.1G 547.8M50216K 485.4Mmartin martin 80% akonadi_mixedm OOM killer: [103900.424539] Out of memory: Kill process 6222 (akonadi_mixedma) score 809 or sacrifice child [103900.424547] Killed process 6222 (akonadi_mixedma) total-vm:16966204kB, anon-rss:6681748kB, file-rss:1352kB Expected Results: Sane memory usage during scan of mixed maildir archive folder. Yes, it is large, but still, it doesn´t have to load it all into memory at the same time. martin@merkaba:~ cat /proc/version Linux version 3.14.0-tp520 (martin@merkaba) (gcc version 4.8.2 (Debian 4.8.2-17) ) #52 SMP PREEMPT Mon Mar 31 13:41:48 CEST 2014 martin@merkaba:~ free -m total used free sharedbuffers cached Mem: 7767 2771 4996326 0 1331 -/+ buffers/cache: 1440 6327 Swap:12287 2114 10173 Akonadi, kdepimlibs, kdepim-runtime are git master as of today. KMail is 4.12.4 as from Debian unstable package. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334318] on adding old mail archive mixedmaildir resource consumes tons of memory
https://bugs.kde.org/show_bug.cgi?id=334318 --- Comment #1 from Martin Steigerwald mar...@lichtvoll.de --- Created attachment 86447 -- https://bugs.kde.org/attachment.cgi?id=86447action=edit kern.log with OOM killer stopping mixedmaildir resource good that it did :) -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334318] on adding old mail archive mixedmaildir resource consumes tons of memory
https://bugs.kde.org/show_bug.cgi?id=334318 --- Comment #2 from Martin Steigerwald mar...@lichtvoll.de --- Some data of mixed maildir directory that triggers this behavior: 643M.Amiga.directory 4,0K.Amiga.index 4,0K.Amiga.index.ids 278M.Computer.directory 4,0K.Computer.index 4,0K.Computer.index.ids 2,9G.Debian.directory 4,0K.Debian.index 4,0K.Debian.index.ids 4,0K.hplip-help-ml.index 4,0K.hplip-help-ml.index.ids 69M .KDE.directory 256K.KDE.index 4,0K.KDE.index.ids 6,1G.Linux.directory 4,0K.Linux.index 4,0K.Linux.index.ids 205M.Mitwelt.directory 4,0K.Mitwelt.index 4,0K.Mitwelt.index.ids 10G insgesamt In folders are several mbox files, sorted by year, example: martin@merkaba:~/.local/share/local-mail-archive/.Lichtvoll-Archiv.directory du -sch .Linux.directory/* 12M .Linux.directory/ck-patch-ml-2006-2008 86M .Linux.directory/fsdevel-ml-2008-2009 144M.Linux.directory/fsdevel-ml-2010-2011 35M .Linux.directory/fsdevel-ml-2012-2013 20M .Linux.directory/hplip-help-ml-2007 288M.Linux.directory/kernel-ml-2008 249M.Linux.directory/kernel-ml-2009-1 322M.Linux.directory/kernel-ml-2009-2 532M.Linux.directory/kernel-ml-2009-3 808M.Linux.directory/kernel-ml-2010-1 674M.Linux.directory/kernel-ml-2010-2 154M.Linux.directory/kernel-ml-2011-1 484M.Linux.directory/kernel-ml-2011-2 620M.Linux.directory/kernel-ml-2012-1 691M.Linux.directory/kernel-ml-2012-2 255M.Linux.directory/kernel-ml-2013-1 15M .Linux.directory/lug-frankfurt-ml 2,1M.Linux.directory/savage40-ml-2004-2009 11M .Linux.directory/suspend2-users-ml-2006 247M.Linux.directory/thinkpad-ml-2005-2009 78M .Linux.directory/xfs-ml-2006-2008 5,6Ginsgesamt I can´t share this as is, at least the Amiga directory contains confidential stuff. I can share the Linux, KDE and Debian directories I think. Maybe except lug-frankfurt-ml and some folders. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334318] on adding old mail archive mixedmaildir resource consumes tons of memory
https://bugs.kde.org/show_bug.cgi?id=334318 --- Comment #3 from Martin Steigerwald mar...@lichtvoll.de --- I tried AKONADI_VALGRIND=akonadi_mixedmaildir_resource AKONADI_VALGRIND_SKIN=memcheck and after a short time got before quitting Akonadi server again after having trigger resync of mixedmaildir resource I got: ==7016== ==7016== HEAP SUMMARY: ==7016== in use at exit: 4,983,818 bytes in 92,727 blocks ==7016== total heap usage: 19,700,956 allocs, 19,608,229 frees, 210,374,310,427 bytes allocated ==7016== ==7016== LEAK SUMMARY: ==7016==definitely lost: 6,656 bytes in 26 blocks ==7016==indirectly lost: 2,151 bytes in 101 blocks ==7016== possibly lost: 640,874 bytes in 13,258 blocks ==7016==still reachable: 4,334,137 bytes in 79,342 blocks ==7016== suppressed: 0 bytes in 0 blocks ==7016== Rerun with --leak-check=full to see details of leaked memory ==7016== ==7016== For counts of detected and suppressed errors, rerun with: -v ==7016== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) ProcessControl: Application valgrind stopped unexpectedly ( Process crashed ) Application 'valgrind' crashed. No restart! I think I only get it on exit... would that work? Well I can leave it running for a while and see. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334320] New: since kde 4.13.0 event no more sync
https://bugs.kde.org/show_bug.cgi?id=334320 Bug ID: 334320 Summary: since kde 4.13.0 event no more sync Classification: Unclassified Product: Akonadi Version: 4.13 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Google Resource Assignee: dvra...@redhat.com Reporter: philippe.roub...@free.fr CC: kdepim-bugs@kde.org i updated from kde 4.12.4 to 4.13.0 if i create an event in korganizer then it not synchronized to google agenda . i wait during one day but no sync . Reproducible: Always -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334318] on adding old mail archive mixedmaildir resource consumes tons of memory
https://bugs.kde.org/show_bug.cgi?id=334318 --- Comment #4 from Martin Steigerwald mar...@lichtvoll.de --- Well got more information with AKONADI_VALGRIND_OPTIONS=--leak-check=full but still only about 6500 bytes left... so either I need to have this run for a rather long time… or I need a different approach. As valgrind seems to detect errors at exit time, it possibly doesn´t even catch the runtime usage. As technically spoken this may not be a leak, but regular memory usage. Please advice. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 333403] Message list quick filter only finds few messages or none at all
https://bugs.kde.org/show_bug.cgi?id=333403 T Kleindienst t.kleindie...@web.de changed: What|Removed |Added CC||t.kleindie...@web.de --- Comment #1 from T Kleindienst t.kleindie...@web.de --- I can confirm this behaviour (latest Kubuntu w KDE 4.13) -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 334112] quick search (baloo/xapian) omits a lot of emails
https://bugs.kde.org/show_bug.cgi?id=334112 --- Comment #1 from T Kleindienst t.kleindie...@web.de --- duplicate with https://bugs.kde.org/show_bug.cgi?id=333403 ? -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334280] IMAP Synchronisation with GMAIL takes 13 minutes to complete !!
https://bugs.kde.org/show_bug.cgi?id=334280 --- Comment #4 from Raymond Wooninck tittiatc...@gmail.com --- (In reply to comment #3) The problem with gmail is that it's CONDSTORE support is broken (I think it was something with the tag folders?), and we therefore have to fetch all flags on every sync. I think the resource simply ignored flag changes But shouldn't this generate network traffic ? Because the flags needs to be retrieved from the server, but during this period I do not see any traffic at all until it reaches the point where it can retrieve some new email. Sorry if I introduced performance problems, but I'm generally preferring correctness over performance, but we can re-add optimizations as necessary. Correctness is fine, but in this world Performance is more important to the users. And it seems that this correctness also creates the situation that the IMAP resource is no longer fast enough and starts blocking itself. (As reported in the other bug). I guess that the IMAP resource now has reached a point where its developers should decide what it actually supports. If the requirement is that it needs a correct CONDSTORE, then support for gmail should be dropped. Maybe moving the gmail support to a separate resource would be much better, so that this specific gmail resource can have all the things required to support a broken GMAIL. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 334175] Local Folders are not set to online at KMail startup
https://bugs.kde.org/show_bug.cgi?id=334175 --- Comment #1 from Jonathan Marten j...@keelhaul.me.uk --- I've investigated this further and found that my kmail2rc config file had an additional config key to switch the resource offline at exit: [Resource akonadi_maildir_resource_0] CheckOnStartup=true IncludeInManualChecks=true OfflineOnShutdown=true So this explains why the resource was initially offline - it got set that way at the last exit from KMail and this persists over restart of the Akonadi server. I don't know how this setting got into the file, there is no GUI for it (although there may have been in the past) and I don't remember ever editing it in manually. Even without this setting, though, KMail should still ensure that the resource is online at startup - it would not be sensible for them to stay offline for any reason. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334280] IMAP Synchronisation with GMAIL takes 13 minutes to complete !!
https://bugs.kde.org/show_bug.cgi?id=334280 --- Comment #5 from Christian Mollekopf mollek...@kolabsys.com --- (In reply to comment #4) (In reply to comment #3) The problem with gmail is that it's CONDSTORE support is broken (I think it was something with the tag folders?), and we therefore have to fetch all flags on every sync. I think the resource simply ignored flag changes But shouldn't this generate network traffic ? Because the flags needs to be retrieved from the server, but during this period I do not see any traffic at all until it reaches the point where it can retrieve some new email. This should generate network traffic indeed. Sorry if I introduced performance problems, but I'm generally preferring correctness over performance, but we can re-add optimizations as necessary. Correctness is fine, but in this world Performance is more important to the users. And it seems that this correctness also creates the situation that the IMAP resource is no longer fast enough and starts blocking itself. (As reported in the other bug). That's just a regular bug that needs to be fixed. I guess that the IMAP resource now has reached a point where its developers should decide what it actually supports. If the requirement is that it needs a correct CONDSTORE, then support for gmail should be dropped. Maybe moving the gmail support to a separate resource would be much better, so that this specific gmail resource can have all the things required to support a broken GMAIL. The IMAP resource supports vanilla IMAP plus extensions as required/useful. If we have to employ certain workarounds in order to make the experience better with servers that don't implement all the necessary extensions, then I'm open to that as long as it doesn't become a maintenance burden. Daniel is already working on a specialized IMAP resource that implements the GMAIL specific extensions, so that will be covered eventually. But I'd still expect the plain IMAP resource to work reasonably well with GMAIL as long as they provide regular IMAP. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[knotes] [Bug 334345] New: KNotes fails to run if Kontact/KMail is already running
https://bugs.kde.org/show_bug.cgi?id=334345 Bug ID: 334345 Summary: KNotes fails to run if Kontact/KMail is already running Classification: Unclassified Product: knotes Version: 4.13 Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: grave Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: snow...@mtaonline.net CC: myr...@kde.org If Kontact/KMail is running, launching KNotes incorrectly takes you to Kontact/KMail application but does not present a KNote. If Kontact/KMail is not running, KNotes launches correctly and presents a KNote for editing. Reproducible: Always Steps to Reproduce: 1. Launch Kontact/Kmail 2. Launch KNotes 3. KNotes fails to load Actual Results: KNotes takes me to my running instance of Kontact/KMail and opens no notes. Expected Results: KNotes should launch and present a KNote on the desktop for editing. KNotes does work properly if Kontact/KMail isn't running. When Kontact/KMail is running, KNotes fails to launch. Interestingly, if I launch KNotes without Kontact/KMail running, in which case KNotes loads and operates properly, to include placement of the running KNotes icon in the System Tray, and I then launch Kontact/KMail, the Popup Notes in Kontact/KMail is unfunctional. If I then quit KNotes, Kontact/KMail Popup Notes performs normally. Kubuntu: 14.04 64-bit KDE: 4.13.0 KNotes: 4:4.13.0-0ubuntu1 Kontact: 4:4.13.0-0ubuntu1 KMail: 4:4.13.0-0ubuntu1 Kernel: 3.13.0-24-generic CPU: Intel i3 M380 -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[knotes] [Bug 334345] KNotes fails to run if Kontact/KMail is already running
https://bugs.kde.org/show_bug.cgi?id=334345 --- Comment #1 from Paul Loughman snow...@mtaonline.net --- If I create a KNote with Kontact/KMail not running, save/close KNotes and then launch Kontact/KMail and click on Popup Notes, the note created with KNotes is shown and editable. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[knotes] [Bug 334345] KNotes fails to run if Kontact/KMail is already running
https://bugs.kde.org/show_bug.cgi?id=334345 --- Comment #2 from Paul Loughman snow...@mtaonline.net --- If KNotes is not running and I create a Popup Notes in Kontact/KMail and then quite Kontact/Kmail, launching KNotes sees/presents the Popup Note created in Kontact/KMail. -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334280] IMAP Synchronisation with GMAIL takes 13 minutes to complete !!
https://bugs.kde.org/show_bug.cgi?id=334280 --- Comment #6 from Raymond Wooninck tittiatc...@gmail.com --- (In reply to comment #5) This should generate network traffic indeed. Strangely enough I didn't notice any network traffic during this period. As indicated network traffic is only visible around the end. That's just a regular bug that needs to be fixed. Ok. Just strange that it seems only to hit the gmail IMAP. Daniel is already working on a specialized IMAP resource that implements the GMAIL specific extensions, so that will be covered eventually. That is great news :) I will let him know that he already found a test person for it :) But I'd still expect the plain IMAP resource to work reasonably well with GMAIL as long as they provide regular IMAP. Ok. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334269] Email retrieval comes to a full HALT after BatchFetcher::fetchNextBatch: fetchNextBatch called while fetch is in process error
https://bugs.kde.org/show_bug.cgi?id=334269 Christian Mollekopf chrig...@fastmail.fm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Latest Commit||http://commits.kde.org/kdep ||im-runtime/c8763c863111afe9 ||9cda997bb9ca7e481d0e5142 --- Comment #2 from Christian Mollekopf chrig...@fastmail.fm --- Git commit c8763c863111afe99cda997bb9ca7e481d0e5142 by Christian Mollekopf. Committed on 04/05/2014 at 19:29. Pushed by cmollekopf into branch 'master'. IMAP-Resource: Fixed stuck BatchFetcher The continuation request can be delivered while a fetch job is in progress if we deliver too many messages (which is likely with the uid based fetches where we can't predict the exact amount of fetched messages). In this case we need to remember the continuation request, and automatically proceed. This causes m_fetchedItemsInCurrentBatch to be off by the messages we delivered too many, but that's not a problem as it means we just deliver too many messages during every batch. M +11 -1resources/imap/retrieveitemstask.cpp http://commits.kde.org/kdepim-runtime/c8763c863111afe99cda997bb9ca7e481d0e5142 -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334280] IMAP Synchronisation with GMAIL takes 13 minutes to complete !!
https://bugs.kde.org/show_bug.cgi?id=334280 --- Comment #7 from Christian Mollekopf mollek...@kolabsys.com --- (In reply to comment #6) (In reply to comment #5) This should generate network traffic indeed. Strangely enough I didn't notice any network traffic during this period. As indicated network traffic is only visible around the end. Please let me know if the situation is improved or still the same with the fix for the other bug. Flag fetching definitely is slower because I'm currently fetching the flags just as messages in batches of 100 to avoid overloading akonadi. This obviously results in many roundtrips, and I suppose the batchsize could be greatly increased for flags (because a lot less data than full messages). That's just a regular bug that needs to be fixed. Ok. Just strange that it seems only to hit the gmail IMAP. It was a timing issue, and it only appeared if the network connection is the bottleneck. Apparently gmail is slow ;-) Daniel is already working on a specialized IMAP resource that implements the GMAIL specific extensions, so that will be covered eventually. That is great news :) I will let him know that he already found a test person for it :) But I'd still expect the plain IMAP resource to work reasonably well with GMAIL as long as they provide regular IMAP. Ok. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail] [Bug 117972] Random crashes on glibc double-free when displaying messages
https://bugs.kde.org/show_bug.cgi?id=117972 Rémi Benoit r3m1.ben...@gmail.com changed: What|Removed |Added Resolution|DUPLICATE |FIXED Latest Commit||http://commits.kde.org/zans ||hin/a4960b99578620374ac2a10 ||86a0c94f415b798eb --- Comment #4 from Rémi Benoit r3m1.ben...@gmail.com --- Git commit a4960b99578620374ac2a1086a0c94f415b798eb by Rémi Benoit. Committed on 01/05/2014 at 16:30. Pushed by remibenoit into branch 'master'. Implement Note serializer for Akonadi backend M +1-0src/akonadi/CMakeLists.txt M +15 -6src/akonadi/akonadiserializer.cpp M +1-1tests/testlib/CMakeLists.txt M +1-1tests/units/akonadi/CMakeLists.txt M +133 -0tests/units/akonadi/akonadiserializertest.cpp http://commits.kde.org/zanshin/a4960b99578620374ac2a1086a0c94f415b798eb -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334269] Email retrieval comes to a full HALT after BatchFetcher::fetchNextBatch: fetchNextBatch called while fetch is in process error
https://bugs.kde.org/show_bug.cgi?id=334269 --- Comment #3 from Raymond Wooninck tittiatc...@gmail.com --- I can confirm that with this commit the HALT situation is no longer occurring. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334280] IMAP Synchronisation with GMAIL takes 13 minutes to complete !!
https://bugs.kde.org/show_bug.cgi?id=334280 --- Comment #8 from Raymond Wooninck tittiatc...@gmail.com --- (In reply to comment #7) (In reply to comment #6) (In reply to comment #5) This should generate network traffic indeed. Strangely enough I didn't notice any network traffic during this period. As indicated network traffic is only visible around the end. Please let me know if the situation is improved or still the same with the fix for the other bug. With the fix for the other bug, the synchronization went back to about 5 minutes and now I see network traffic during the flag retrieval. What exactly does the number mean in this line : akonadi_imap_resource_16(30157)/kdepimlibs (kimap) BatchFetcher::fetchNextBatch: Fetching 257301 to 257400 Does that mean that I have 257400 emails in that folder ? If so, then something else is wrong. I know that I have a number of high volume email lists (e.g. kde-com...@kde.org), but I am deleting the emails from there every 3 days to reduce the total number of emails. I also cleaned up in gmail.com itself, so I shouldn't have those many emails. Flag fetching definitely is slower because I'm currently fetching the flags just as messages in batches of 100 to avoid overloading akonadi. This obviously results in many roundtrips, and I suppose the batchsize could be greatly increased for flags (because a lot less data than full messages). Can I increase the number somewhere ? Just to test if I can find a better number for my system and to retrieve things a little faster ? -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334280] IMAP Synchronisation with GMAIL takes 13 minutes to complete !!
https://bugs.kde.org/show_bug.cgi?id=334280 --- Comment #9 from Christian Mollekopf mollek...@kolabsys.com --- (In reply to comment #8) (In reply to comment #7) (In reply to comment #6) (In reply to comment #5) This should generate network traffic indeed. Strangely enough I didn't notice any network traffic during this period. As indicated network traffic is only visible around the end. Please let me know if the situation is improved or still the same with the fix for the other bug. With the fix for the other bug, the synchronization went back to about 5 minutes and now I see network traffic during the flag retrieval. What exactly does the number mean in this line : akonadi_imap_resource_16(30157)/kdepimlibs (kimap) BatchFetcher::fetchNextBatch: Fetching 257301 to 257400 It means UID's 257301 to 257400 are fetched which only correlates to the number of messages that ever have been in the folder (not to the amount you currently have). Does that mean that I have 257400 emails in that folder ? If so, then something else is wrong. I know that I have a number of high volume email lists (e.g. kde-com...@kde.org), but I am deleting the emails from there every 3 days to reduce the total number of emails. I also cleaned up in gmail.com itself, so I shouldn't have those many emails. Flag fetching definitely is slower because I'm currently fetching the flags just as messages in batches of 100 to avoid overloading akonadi. This obviously results in many roundtrips, and I suppose the batchsize could be greatly increased for flags (because a lot less data than full messages). Can I increase the number somewhere ? Just to test if I can find a better number for my system and to retrieve things a little faster ? In imapresource.cpp (setItemSyncBatchSize) we define the batch size. This directly correlates to the number of messages that are loaded into memory, so I wouldn't make this one too big. In retrieveitemstask.cpp:668 you could increase the passed-in batch-size for flag fetching only. I think it should work if you simply set a multiplier (e.g. 10*batchSize()). It's not configurable in a configfile. -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334269] Email retrieval comes to a full HALT after BatchFetcher::fetchNextBatch: fetchNextBatch called while fetch is in process error
https://bugs.kde.org/show_bug.cgi?id=334269 --- Comment #4 from Christophe Giboudeaux cgiboude...@gmx.com --- Do the last changes switch the imap resource to read only while it's refetching ? I'm seeing this kind of messages (not directly related to this commit but also visible with it): akonadi_imap_resource_0(11329) RetrieveItemsTask::onExpungeDone: Expunge failed: Expunge failed, server replied: A09 NO mailbox selected READ-ONLY akonadi_imap_resource_1(11332) RetrieveItemsTask::onExpungeDone: Expunge failed: Expunge failed, server replied: A09 NO mailbox selected READ-ONLY akonadi_imap_resource_0(11329) RetrieveItemsTask::onExpungeDone: Expunge failed: Expunge failed, server replied: A15 NO mailbox selected READ-ONLY akonadi_imap_resource_1(11332) RetrieveItemsTask::onExpungeDone: Expunge failed: Expunge failed, server replied: A15 NO mailbox selected READ-ONLY which disappear if I reroll kdepim-runtime to a commit from before the last changes (server capabilities: IMAP4REV1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+ LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=EKTX SASL-IR SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST ) -- You are receiving this mail because: You are on the CC list for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[kmail2] [Bug 331156] Display of HTML-Message extremely slow
https://bugs.kde.org/show_bug.cgi?id=331156 anmeldo...@posteo.de changed: What|Removed |Added CC||anmeldo...@posteo.de -- You are receiving this mail because: You are the assignee for the bug. ___ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs
[Akonadi] [Bug 334351] New: akonadi thread crashes on startup in KABCResource::collectionChanged
https://bugs.kde.org/show_bug.cgi?id=334351 Bug ID: 334351 Summary: akonadi thread crashes on startup in KABCResource::collectionChanged Classification: Unclassified Product: Akonadi Version: 4.13 Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: walch.mar...@web.de Application: akonadi_kabc_resource (4.13) KDE Platform Version: 4.13.0 Qt Version: 4.8.5 Operating System: Linux 3.12.13-gentoo-gnu x86_64 Distribution: NAME=Gentoo -- Information about the crash: - What I was doing when the application crashed: Turned on the computer with auto login active. I left the room before the boot loader showed up and when I came back, KDE had finished starting up and drkonqi told me that something crashed. Then I tried akonadictl restart from command line and the same crash happened again. The backtrace is now from this second crash. This crash never happened before. I did not change any program or library during or since the previous KDE session. When thinking of what I did in the last KDE session that might be related to the crash is - set up desktop search to not search in /home - delete about 500 obsolete emails (from roughly 11.000), move some emails into subfolders The last lines of console output before the crash were these: akonadi_kabc_resource_0(3721)/kresources KRES::Factory::self: akonadi_kabc_resource_0(3721)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from /var/tmp/kdecache-neoHgE65K/ksycoca4 akonadi_kabc_resource_0(3721)/kresources KRES::ManagerImpl::ManagerImpl: akonadi_kabc_resource_0(3721) KABCResource::doSetOnline: online true resource 0x0 akonadi_kabc_resource_0(3721)/kresources KRES::ManagerImpl::readConfig: akonadi_kabc_resource_0(3721)/kresources KRES::Factory::self: akonadi_kabc_resource_0(3721)/libakonadi Akonadi::SessionPrivate::dataReceived: Server protocol version is: 37 akonadi_archivemail_agent(3715)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from /var/tmp/kdecache-neoHgE65K/ksycoca4 AkonadiAgentServer(3723)/akonadiresource (kalarm) KAlarmResource::readFromFile: /home/neo/.kde4/share/apps/kalarm/expired.ics AkonadiAgentServer(3723)/kdepimlibs (kcalcore) KCalCore::ICalFormat::load: /home/neo/.kde4/share/apps/kalarm/expired.ics AkonadiAgentServer(3723)/kdepimlibs (kalarmcal) KAlarmCal::Private::readKAlarmVersion: File= /home/neo/.kde4/share/apps/kalarm/expired.ics , version= 2.7.0 AkonadiAgentServer(3723)/kio (KDirWatch) KDirWatchPrivate::addEntry: Added File /home/neo/.kde4/share/apps/kalarm/expired.ics for [KDirWatch-1] Database akonadi opened using driver QMYSQL AkonadiAgentServer(3723)/libakonadi Akonadi::SessionPrivate::dataReceived: Server protocol version is: 37 akonadi_archivemail_agent(3715)/libakonadi Akonadi::SessionPrivate::init: Archive Mail Kernel ETM akonadi_archivemail_agent(3715)/libakonadi Akonadi::SessionPrivate::reconnect: connectToServer /tmp/akonadi-neo.j3Vexm/akonadiserver.socket QDBusObjectPath Akonadi::Server::NotificationManager::subscribeV2(const QString, bool) Akonadi::Server::NotificationManager(0x1612010) akonadi_archivemail_agent_3715_OQYUvH true QDBusObjectPath Akonadi::Server::NotificationManager::subscribeV2(const QString, bool) Akonadi::Server::NotificationManager(0x1612010) akonadi_archivemail_agent_3715_tE9TbE true akonadi_archivemail_agent(3715)/libakonadi Akonadi::EntityTreeModelPrivate::startFirstListJob: GEN true false false akonadi_archivemail_agent(3715)/libakonadi Akonadi::SessionPrivate::dataReceived: Server protocol version is: 37 akonadi_archivemail_agent(3715)/libakonadi Akonadi::SessionPrivate::dataReceived: Server protocol version is: 37 Database akonadi opened using driver QMYSQL AkonadiAgentServer(3724)/kio (KDirWatch) KDirWatchPrivate::KDirWatchPrivate: INotify available: true AkonadiAgentServer(3724)/akonadiresource (kalarm) KAlarmResource::KAlarmResource: akonadi_kalarm_resource_2 Agent instance created in separate process. AkonadiAgentServer(3722)/kio (KDirWatch) KDirWatchPrivate::KDirWatchPrivate: INotify available: true AkonadiAgentServer(3722)/akonadiresource (kalarm) KAlarmResource::KAlarmResource: akonadi_kalarm_resource_0 Agent instance created in separate process. KCrash: Application 'akonadi_kabc_resource' crashing... KCrash: Attempting to start /usr/lib64/kde4/libexec/drkonqi from kdeinit The crash can be reproduced sometimes. -- Backtrace: Application: Adressbuch vom Typ KDE-Adressbuch (herkömmlich) (akonadi_kabc_resource), signal: Segmentation fault Using host libthread_db library /lib64/libthread_db.so.1. [KCrash Handler] #6 0x0040efe3 in KABCResource::collectionChanged (this=0x12f7b00, collection=...) at
