Calendar-Sync not working on iPad



  • Hi,

    I’m currently trying to get z-push running with a custom backend. Unfortunately I encounter problems with an iPad and can’t find the error.
    The same setup works fine with Thunderbird and the TbSync plugin.
    But on the iPad I end up in a loop - which wouldn’t be too bad. But the transmission in loop-mode doesn’t work either and suspends after the first element.
    I get a similar behavior with an Android-device (Samsung) but the loop-mode seems to be able to get around the error here, the transmission 1 by 1 works.
    My best guess is that it has something to do with changing uuids/synckeys but thats just because of the error message i get shortly before loop-mode.

    15/05/2019 13:32:23 [ 3259] [DEBUG] LoopDetection->ProcessLoopDetectionAddStatus: 'myappointments' with status 1
    15/05/2019 13:32:23 [ 3259] [DEBUG] WBXMLEncoder->startWBXML() type: vnd.ms-sync.wbxml
    15/05/2019 13:32:23 [ 3259] [DEBUG] Folder type: Calendar
    15/05/2019 13:32:23 [ 3259] [WBXML] O  <Synchronize>
    15/05/2019 13:32:23 [ 3259] [WBXML] O   <Folders>
    15/05/2019 13:32:23 [ 3259] [WBXML] O    <Folder>
    15/05/2019 13:32:23 [ 3259] [WBXML] O     <SyncKey>
    15/05/2019 13:32:23 [ 3259] [WBXML] O     {d799fedd-8335-4d2d-aefa-74c6fcf17353}2
    15/05/2019 13:32:23 [ 3259] [WBXML] O     </SyncKey>
    15/05/2019 13:32:23 [ 3259] [WBXML] O     <FolderId>
    15/05/2019 13:32:23 [ 3259] [WBXML] O     myappointments
    15/05/2019 13:32:23 [ 3259] [WBXML] O     </FolderId>
    15/05/2019 13:32:23 [ 3259] [WBXML] O     <Status>
    15/05/2019 13:32:23 [ 3259] [WBXML] O     1
    15/05/2019 13:32:23 [ 3259] [WBXML] O     </Status>
    15/05/2019 13:32:23 [ 3259] [DEBUG] LoopDetection->Detect(): folderid:'myappointments' uuid:'d799fedd-8335-4d2d-aefa-74c6fcf17353' counter:'1' max:'25' queued:'9'
    15/05/2019 13:32:23 [ 3259] [DEBUG] LoopDetection->Detect(): UUID changed for folder
    15/05/2019 13:32:23 [ 3259] [DEBUG] LoopDetection->Detect(): UUID changed and while items where sent to device - forcing loop mode
    15/05/2019 13:32:23 [ 3259] [DEBUG] LoopDetection->Detect(): case 3.1 detected - loop detected, init loop mode
    15/05/2019 13:32:23 [ 3259] [DEBUG] LoopDetection->Detect(): loop data: loopcount(1), maxCount(10), queued(9), ignored(false)
    15/05/2019 13:32:23 [ 3259] [WARN] Mobile loop detected! Messages sent to the mobile will be restricted to 1 items in order to identify the conflict
    15/05/2019 13:32:23 [ 3259] [WBXML] O     <MoreAvailable/>
    

    Maybe someone with more experience in z-push can get me on the right track.
    If u need more information to narrow down the problem, feel free to tell me how i am able to help u.

    Thanks alot


  • Kopano

    Hi Dennis,

    the short log excerpt is not very helpful. It’s more important to know what happened before, what caused the loop. Usually it’s because Z-Push sends data the device can’t process, so it might be a good idea to analyse what you’re getting from the source, if the backend process it properly.

    It’s difficult to say anything without knowing the code.

    Manfred



  • Hi Manfred,

    thanks for your reply. I am pretty sure the backend works fine, cause other devices are able to process the data without errors. I even tried to tune down the data sent to the device by only setting the subject, the start- and the enddate (in my backend), clearing the loop and forcing a resync. The result stayed the same - the wbxml-log however contained only some basic data, i even got log entries that said some values were set to default.
    Would it help to provide a full log of the first sync-attempts?
    What does case 3.1 for loop-detection mean, is a changing uuid the normal behavior?

    Dennis


  • Kopano

    Hi Dennis,

    in your first post you mentioned that an Android device also goes into loop mode. Going into loop mode is not a normal case. It means that device requests same data over and over again.

    The loop detection is explained in Z-Push wiki: https://wiki.z-hub.io/display/ZP/Loop+detection and also there are quite extensive comments in loopdetection.php starting at line 650.

    What are your plans for this backend anyway? If you publish it under AGPL v3 or contribute under AGPL v3 to be a part of the official Z-Push release, we’ll gladly review it and grant you permissions to Z-Push git. If you prefer to maintain it closed source, you have to understand that we will prioritise Z-Push issues from the open source backends and it might take time until we get to your issues.

    Manfred



  • Hi Manfred,

    you are right an Android device goes into loop mode aswell. The behavior i question is, that the iPad is not able to sync the calendar but contacts and tasks work fine, the Android device is not able to sync calendar nor tasks but contacts and Thunderbird is able to sync all 3 kinds.
    That’s why I doubt that it’s something related to the backend itself, or do I interpret too much into the behavior of individual devices here? Especially cause my backend does the same thing for all 3 kinds - getting the data from an external source, parsing them and creating SyncObjects with the data to transfer them to the ActiveSync-protocol.
    If something would fail for all devices i could understand it but that’s what confuses me - so i am more driven to think it’s device-related. Maybe i just don’t want to accept there is a error in my backend that i overlook :D

    The backend will most likely stay closed source so i understand if you concentrate your time on the open source backends.

    Thanks for your time anyway

    Dennis


Log in to reply