[smw]

I have two devices: a Samsung Galaxy Note 12.2 running Android 5.0.2 and a Galaxy Note 9 with Android 10 (in both cases, the most recent Android version available). Both have MobileSheets 3.5.3 (and curiously, each device received that version twice, in the form of two separate upgrades, but I digress).

I rely on the "Sync Library" functionality to push updates to the phone from the tablet, and until version 3.5.3 this has always worked as expected.

In 3.5.3, I've consistently seen the following behavior:  The synchronization operation starts, the phone (receiving) claims that the sync has finished successfully, but at the same time the tablet reports that the sync is only about 3% finished. The first time this happened I tried to back out on the tablet, and ended up having to reboot the tablet to get MobileSheets to respond. Today I let it go to see what would happen, and the tablet eventually reported that the sync finished, after a wait of about five minutes or so.

I don't know whether this is considered a bug, but it's definitely new and unwanted behavior.

     - Steven

[Zubersoft]

Hello Steven,

The only code that was modified with version 3.5.3 related to the synchronization functionality was to properly handle canceling out when you are prompted to select a file when a conflict occurs where MobileSheets can't properly match up songs on each devices. That should have no impact on the way in which the sync proceeds normally. So I'm not sure why you are seeing that behavior, but it's certainly not new to 3.5.3. What's strange about the issue you reported is that the code is set up so that the server waits until it receives a message from the client indicating that the client has finished processing changes on its end (the transferring of necessary files and such). If you are seeing the sync finish on the server tablet, that means it got the message it wanted from the client indicating the sync was complete even though the client tablet only showed 3% completion. I have no idea how that is possible. I can't reproduce that myself so I'm not sure how to go about investigating it at the moment. I'll have to spend some time with test libraries seeing if I can figure out some way to see that behavior. How large is the library you are working with?

Thanks,
Mike

[smw]

Hello Steven,

The only code that was modified with version 3.5.3 related to the synchronization functionality was to properly handle canceling out when you are prompted to select a file when a conflict occurs where MobileSheets can't properly match up songs on each devices. That should have no impact on the way in which the sync proceeds normally. So I'm not sure why you are seeing that behavior, but it's certainly not new to 3.5.3. What's strange about the issue you reported is that the code is set up so that the server waits until it receives a message from the client indicating that the client has finished processing changes on its end (the transferring of necessary files and such). If you are seeing the sync finish on the server tablet, that means it got the message it wanted from the client indicating the sync was complete even though the client tablet only showed 3% completion. I have no idea how that is possible. I can't reproduce that myself so I'm not sure how to go about investigating it at the moment. I'll have to spend some time with test libraries seeing if I can figure out some way to see that behavior. How large is the library you are working with?

Thanks,
Mike

I understand that the behavior I'm seeing wasn't introduced in 3.5.3, but I definitely never saw it before, and I run the device sync every time I add new songs or update the PDF for an existing song; I just checked, and there have been 14 such additions or changes so far since the beginning of this month.

This probably isn't related to the fact that Google Play served the update for 3.5.3 twice (i.e., 3.5.2 was updated to 3.5.3, but then a couple of days later 3.5.3 was supposedly updated to 3.5.3; I don't understand how or why that happened, but it did happen on both devices), but it's worth mentioning just in case.

Based on your reply, I'm not certain my problem description was clear. Just to be sure:
1) I start the sync as usual, pushing from the tablet to the phone (the sync is configured to send only in that direction).
2) The phone reports that the sync is complete, typically after about 30 seconds or so (I haven't actually timed it, but it feels about that length of time).
3) At the same time, the progress bar on the tablet shows 3% completion.
4) After a few minutes (again, I didn't actually time it, but that's probably a close approximation) the tablet reports 100% completion.

Since this happened, it's been happening repeatably on every sync.

My library contains 2040 songs, and a backup (including mp3 files) occupies 4.4 Gb.

Please let me know what I can do to help test or debug this.

[Zubersoft]

If you want to create library backups from both devices and share them with mike@zubersoft.com, I can try to sync two devices together to get more information on what is happening. Without knowing more details about what is occurring while the tablet is at 3% completion, it sounds to me like many files are having to be sent over to the client with every sync. If you created a library backup file on the tablet and restored that on the phone, that could reset things back into a good state which would make future synchronizations work better. I'll run some tests today with a couple of devices using a few larger libraries to see if I'm able to reproduce what you described.

Thanks,
Mike

[Zubersoft]

One follow-up question - are you using the "Update Client" sync behavior or "two-way"? Also what merge behavior is selected? Those will have a large impact on how the sync proceeds.

Thanks,
Mike

[Zubersoft]

I've investigated this further and found the cause - I updated libraries from Google and they added backward compatible emoji support to all text components. Unfortunately, this results in disastrously slow performance when a text component is appended to over and over, which is what happens with the library sync. So the sync actually is finishing as fast as is shown on the client side, but the server side is still trying to update the text component to show the results of the sync and it's taking minutes to process. I'm going to disable this emoji support as it's absolutely unnecessary for MobileSheets in my opinion which should restore the performance. I'll release an update today to address this.

Mike

[smw]

I've investigated this further and found the cause - I updated libraries from Google and they added backward compatible emoji support to all text components. Unfortunately, this results in disastrously slow performance when a text component is appended to over and over, which is what happens with the library sync. So the sync actually is finishing as fast as is shown on the client side, but the server side is still trying to update the text component to show the results of the sync and it's taking minutes to process. I'm going to disable this emoji support as it's absolutely unnecessary for MobileSheets in my opinion which should restore the performance. I'll release an update today to address this.

Mike

Wow!  I don't have any idea how you tracked that down, but I'm impressed (with you, not with Google ). I've already installed 3.5.4 on both devices, and the sync is once more working as expected.

Your previous questions are suddenly a lot less relevant :-), but for the record:

   - I'm using "Update Client" mode, because I always add or update songs on the tablet. The only reasons for having the database on my phone are 1) as an extra backup, because I'm paranoid^Wcareful :-), and 2) in case I want to check something at a time when I don't have the tablet with me. I've never needed or wanted to sync changes from the phone back to the tablet.

   - I have the merge behavior set to "Always use data from server", for the same reasons.

   - I doubt that the sync usually transfers many files at a time, assuming it only copies over files that have changed since the last sync; sometimes I add about a dozen songs at a time, but usually it's only two or three at a time at most.

Anyhow, thank you so much for fixing this so quickly.