06-22-2018, 03:07 AM
JBlyth - thanks for the logs. It looks like a threading issue when annotations are synchronized due to the fact that on Windows, some of the data for Annotations has to be handled on the UI thread. I'll get a fix in place for that.
BRX - With a library as large as you are working with, it's possible that the status box filled up with so much text that it couldn't append any more. That's not supposed to happen, as there isn't supposed to be a fixed limit on how much text you can add in one of those components, but I do know that some manufacturers did add their own limitations. I may have to try putting a hard limit in place, or at least provide a way to clear the box if needed, but I don't love either approach as I want users to be able to have access to the results of the merge if needed. The progress bar shouldn't have been stuck unless the UI thread itself was stuck because it couldn't append any more text to the status box.
MSP first checks before sending files between the devices if a file already exists in the destination location. If it exists, then it does a checksum comparison to ensure that the file exactly matches what the other device has. If it's an exact match, then it will not be sent. If there is a difference, the existing file will be overwritten and replaced.
Adding conditions to what data is backed up by the companion (or in MobileSheetsPro itself) is not something I want to do. It adds significant complexity not only to the back-up process, but to the restore process as well, as I can no longer guarantee that songs that are referenced in the database will be found in the backup file. I really don't want to modify the backup/restore code and the backup file format to have to deal with that. I'm open to the idea of not including audio in the backup file, as I used to support that in the original MobileSheets, but it does mean that users that enable the copying of audio files in the storage settings (meaning the audio files are managed in the storage location) could potentially find themselves without any audio at all after restoring their backup. The same concerns apply to the merging - adding the ability to filter what songs are going to be a part of the merge on each device means that I can no longer just rely on what's found in the database. Instead, each tablet would have to instruct the other about what songs are going to be participating in the merge, and then I have to add a lot checks for situations where you might say song A on tablet 1 is participating in the merge but that same exact song on tablet 2 is not. While this is something I could potentially support in the future, it would involve having to add an entirely new screen for selecting what songs you want included in the merge, unless I made it very simple and did something like a multi-selection dropdown where you could pick collections or setlists that you want to limit the merge to. If that's sufficient for what you want, then I can add that to the list of future enhancements.
If all you want is to create a backup of the database itself without backing up song files or audio files, then you don't need me to make any changes. Just enable the "Expose Database" setting in the storage, and you can copy mobilesheets.db anywhere you want. This is something I only want advanced users doing, because I don't want angry emails from customers who didn't include files in their backup and lost everything because of it. There is always a balance between giving my power users what they want, and making sure that the larger majority of users with simpler use case scenarios aren't given ample opportunities to shoot themselves in the foot.
As far as the PC companion not finishing the backup, I have heard of people encountering that issue, but I've always struggled to reproduce it myself. It usually means the companion app is waiting for some additional bytes to be sent over the network, but either the tablet never sends them or the companion app doesn't receive them. If the progress shows 100%, you can safely terminate the process in task manager, and the backup file should be perfectly fine.
Thanks,
Mike
BRX - With a library as large as you are working with, it's possible that the status box filled up with so much text that it couldn't append any more. That's not supposed to happen, as there isn't supposed to be a fixed limit on how much text you can add in one of those components, but I do know that some manufacturers did add their own limitations. I may have to try putting a hard limit in place, or at least provide a way to clear the box if needed, but I don't love either approach as I want users to be able to have access to the results of the merge if needed. The progress bar shouldn't have been stuck unless the UI thread itself was stuck because it couldn't append any more text to the status box.
MSP first checks before sending files between the devices if a file already exists in the destination location. If it exists, then it does a checksum comparison to ensure that the file exactly matches what the other device has. If it's an exact match, then it will not be sent. If there is a difference, the existing file will be overwritten and replaced.
Adding conditions to what data is backed up by the companion (or in MobileSheetsPro itself) is not something I want to do. It adds significant complexity not only to the back-up process, but to the restore process as well, as I can no longer guarantee that songs that are referenced in the database will be found in the backup file. I really don't want to modify the backup/restore code and the backup file format to have to deal with that. I'm open to the idea of not including audio in the backup file, as I used to support that in the original MobileSheets, but it does mean that users that enable the copying of audio files in the storage settings (meaning the audio files are managed in the storage location) could potentially find themselves without any audio at all after restoring their backup. The same concerns apply to the merging - adding the ability to filter what songs are going to be a part of the merge on each device means that I can no longer just rely on what's found in the database. Instead, each tablet would have to instruct the other about what songs are going to be participating in the merge, and then I have to add a lot checks for situations where you might say song A on tablet 1 is participating in the merge but that same exact song on tablet 2 is not. While this is something I could potentially support in the future, it would involve having to add an entirely new screen for selecting what songs you want included in the merge, unless I made it very simple and did something like a multi-selection dropdown where you could pick collections or setlists that you want to limit the merge to. If that's sufficient for what you want, then I can add that to the list of future enhancements.
If all you want is to create a backup of the database itself without backing up song files or audio files, then you don't need me to make any changes. Just enable the "Expose Database" setting in the storage, and you can copy mobilesheets.db anywhere you want. This is something I only want advanced users doing, because I don't want angry emails from customers who didn't include files in their backup and lost everything because of it. There is always a balance between giving my power users what they want, and making sure that the larger majority of users with simpler use case scenarios aren't given ample opportunities to shoot themselves in the foot.
As far as the PC companion not finishing the backup, I have heard of people encountering that issue, but I've always struggled to reproduce it myself. It usually means the companion app is waiting for some additional bytes to be sent over the network, but either the tablet never sends them or the companion app doesn't receive them. If the progress shows 100%, you can safely terminate the process in task manager, and the backup file should be perfectly fine.
Thanks,
Mike