[smw]

I'm currently using MobileSheets to 3.8.6 on my Galaxy Note 12.2 (Android 5.0.2, which is the most recent version available), and also on my Galaxy Note 9.

Issue #1: You may recall that version 3.7.5 had an issue where it crashed on startup on devices running older versions of Android. I was one of the people who reported that problem, and I'm grateful that it was fixed so quickly. However, ever since then I'm experiencing a significant increase in the time required to sync my library from my tablet to my phone; the sync used to take less than a minute, but now it takes almost five minutes (for example, I just ran a sync that started at 20:26:57 and finished at 20:31:52 EDT, based on the time stamps reported in the status window).

This may be related to the upgrade, but it's more likely to be related to the fact that before I knew about the cause of the crashes, I tried deleting my library and reinstalling it from a backup. Or of course both of those factors may be coincidental, but they seem worth mentioning. The sync operation still works, but I'd be very grateful if there's a way to speed it up again.  For the record, my sync settings are as follows:

- on the tablet:
      - connect as:  server
      - sync type:  update client
      - all options enabled
      - merge behavior:  always use data from server
      - connect using:  wifi

- on the phone:
      - connect as:  client
      - connect using:  wifi

None of these settings have been changed since before the version 3.7.5 upgrade (in other words, the speed decrease wasn't triggered by a setting change on either of my devices).


Issue #2:  This one may not be fixable easily, or perhaps at all, but it's worth mentioning just in case.  The other day I needed to edit a PDF file on my computer, after which I used the new PDF to replace the existing one for a song already imported into MobileSheets. During the edit, the underlying images were reduced from 600 DPI to 300 DPI for unrelated reasons. The problem is that after swapping the PDF file, all my annotations were sized for 600 DPI and so they appeared four times larger than they should have been for the new PDF. There were many of them, and the easiest workaround on my part was to delete them all and recreated them (which I could do because I still had the old PDF and annotations on my phone).


...and finally, a feature request.  This is very definitely a first-world problem, but I back up my library every time I add a new song. I always use the same backup destination (specifically, a local file, always using the same path and filename). Initiating a backup in this way requires a total of 9 touches, as follows:

    1) open overflow menu
    2) choose Settings
    3) choose Backup and Restore
    4) choose Backup Library
    5) touch the file folder icon to select the backup destination
    6) choose Local File
    7) choose the existing file from the "Select Backup File Name" screen
    8) confirm that I want to replace the existing file
    9) touch OK to start the backup

It would be really nice to have an option (perhaps even directly in the overflow menu, or at least in the Backup and Restore settings screen) to repeat the last backup, intentionally overwriting the previous backup file.  I understand that this would be dangerous in general, but I always sync the backup file to my computer anyway, so overwriting it is the simplest and easiest thing to do.

Thanks,
    - Steven

[Zubersoft]

The logic for the sync hasn't subtantially changed for a very long time. It's very likely that what you are seeing is due to some kind of slowdown with the database access. Figuring out why that is occurring is difficult. If you want to send me backups of the libraries on both your devices, I can test synchronizing that myself to see how long it takes on my devices. Otherwise, I can work with you to test a build where logging information is gathered on which pieces of code are taking the longest amount of time so we can figure out where the slowdown is occuring.

As far as issue #2 - that's to be expected. The annotations are positioned and scaled relative to the initial source page width and height. If you change that, it's going to change the appearance of the annotations. What you should do is permanently embed the annotations in the PDF, then try to downscale the images to 300 dpi. The annotations will be a part of the page then and will scale down like you would expect.

I'll think about the request, but I don't think it would be structured as a "repeat last backup action". I can certainly provide a way to access the backup dialog straight from the library screen, so that would save you few taps, but you'd still have to select the destination. I can consider adding a button on the backup dialog itself that would select the last used location, but this obviously gets messy if the location that was selected was a cloud location as the backup could then fail when you try to start it if the cloud account needs to be authenticated, for example.

Mike

[smw]

With respect to the sync, which option would be preferable for you (i.e., sharing the backups vs. running an instrumented build)?

Regarding the scaling, that's pretty much what I expected, but I had to ask just in case.

For the backup destination issue, what about just having the last destination come up automatically as the default for a new backup? The user could still make a different choice, but making the same choice would require fewer interactions.

[Zubersoft]

I think backups is the easiest first step, and then an instrumented build will be the fallback if we can't gather any useful information from the first test.

Mike

[smw]

Okay, I'll upload the backups to Google Drive and post the URLs when they're available. Each one is 4.5 Gb in size, so it may take a while; I'll make them available as soon as I can.

[smw]

The backups are now up.

They'll be highly similar if not actually identical (the only change I remember since the last sync involved removing some songs from a collection, but I believe the tablet backup was done before that change).  Please let me know when you've downloaded the files so I can delete them from Google Drive.

Also, one more feature request occurred to me, regarding line annotations. Almost all of the lines I draw are intended to be vertical or horizontal (i.e, exactly 0 degrees or exactly 90 degrees), but it's nearly impossible (at least for me) to draw lines that are perfectly vertical or horizontal. Would it be feasible to add an explicit angle setting to the line dialog?

[Zubersoft]

Thank you - I've removed the links from your post as I don't want anyone else downloading your backups. I'll work on testing this out tomorrow. You can take down the files now.

As far as your request, the easiest way to handle that at the moment is to turn on the "Snap to grid" option, as the line will snap to one of the grid lines. If you turn snap to grid off after that, you can manually adjust the position if it does not align with where you want it. I can think of supporting more options in the future such as a setting to control whether the line will draw at any direction, or only in 45 degree increments, for example.

Mike

[smw]

Thank you, I really appreciate your help with this.

I'd forgotten there was a snap to grid option, but it sounds like it would help a lot, so thank you for the reminder. I'd still appreciate a 45-degree increment option when you have time to think about that.

[Zubersoft]

I've done some preliminary analysis and it looks like it took my Android devices 2.5 minutes to sync your library. When I profiled the code, most of the time was spent calculating file hashes. One thing I've been planning to change for a while is I want to store the hashcodes in the database so that they don't have to be recalculated every time during the sync. I will work on these changes and let you know what kind of speed increase occurs after they've been implemented. The first sync after the changes are rolled out will still be the same speed (as the hashes won't be in the database yet), but future syncs after that point should hopefully be considerably faster. I'll let you know what the results are once I've had time to work on this.

Mike

[smw]

That sounds like a great idea.

...and I know the tablet is old and slow by modern standards. Running a full backup on my phone takes than half the time the tablet requires for the same operation. However, this same sync used to be a lot faster; is there any way you can think of that rebuilding the database from a backup may affect its structure?

[Zubersoft]

Smw - Version 3.8.12 is being submitted right now. If you get a chance, can you try the sync out a few times once you are able to get 3.8.12 and let me know if the sync is now faster for you? There is a bug with version 3.8.10 where it won't be faster unless you first either create a library backup file on each device (which calculates the hashes) , then try the sync or take turns making each device the server as it will calculate the hashes. After doing that, then it should be faster with 3.8.10.

Thanks,
Mike

[smw]

If you get a chance, can you try the sync out a few times once you are able to get 3.8.12 and let me know if the sync is now faster for you?

Done, and it is. 3.8.10 was a bit faster than the previous version (approximately 3.5 minutes instead of 5), but 3.8.12 blows that away.

In particular, I just ran two sync operations. The first one took just under one minute (19:55:11 to 19:56:08), and the second took just over 30 seconds (19:58:13 to 19:58:48), with all times as reported in the sync progress window.

Thank you!

   - Steven

[Zubersoft]

That's great news! That definitely sounds like a huge improvement over the times you were seeing before.

Mike

[smw]

That's great news! That definitely sounds like a huge improvement over the times you were seeing before.

Mike

Yes, it's awesome, and I greatly appreciate the work you did to make it possible.

I still don't understand why the sync operation went from under a minute to over five minutes in the first place (as I mentioned originally, I noticed that pretty much immediately after deleting and reloading my library, which may or may not be a coincidence).

But now I no longer need to care about the answer to that question.