> run Akonadi with logging enabled:
> QT_LOGGING_RULES="*=true;qt.*=false" akonadictl restart
>
> or even log the complete IMAP traffic:
> export KIMAP_LOGFILE=/tmp/imap.log
> QT_LOGGING_RULES="*=true;qt.*=false" akonadictl restart
>
> see also > https://techbase.kde.org/KDE_PIM/Akonadi/Debug_IMAP
>
Thank you for the suggestions. I'll start with this one, which is the most
urgent problem.
It appears that when IMAP tries to sync, it gets part way through my mail
account. There are lots of entries reading
org.kde.pim.akonadicore: Received batch: X Already processed: Y Expected
total amount: Z
At some point, though, it fails:
org.kde.pim.kimap: The stream parser raised an exception: Unable to read more
data
org.kde.pim.kimap: The stream parser raised an exception: Unable to read more
data
org.kde.pim.kimap: close
org.kde.pim.kimap: close
org.kde.pim.imapresource.trace: RetrieveItemsTask
org.kde.pim.imapresource: Cancelling this request.
org.kde.pim.akonadicore: The item sync is being rolled-back.
org.kde.pim.akonadicore: ItemSync of collection 20 finished due to user
cancelling
org.kde.pim.imapresource: Fetch job failed "Connection to server lost."
org.kde.pim.imapresource: ""
org.kde.pim.imapresource: Cancel task: ""
org.kde.pim.imapresource.trace: RetrieveCollectionMetadataTask
And the subsequent log messages suggest that it tries to re-establish the
connection. That seems to be a worthy hypothesis. The sync fails and, on each
failure, it rolls back and starts again.
The IMAP logs from the export KIMAP_LOGFILE setting basically shows every
e-mail it's trying to sync, so the files are massive, and it's hard to search
them for meaningful messages.
I have no access to or control over the IMAP server. Does the protocol and/or
Akonadi support picking up where it left off, so it eventually syncs?
